strategic research cluster: space robotics technologies space...

Strategic Research Cluster:

Space Robotics Technologies

SPACE-12-TEC-2018

Guidance Document for

Horizon 2020 Work Programme 2018-2020

Final

25/10/2017

/73

D3.2-Compendium of SRC activities (for call 2)

Date 25/10/2017 Issue 1.6

Report


Due date of deliverable: Month 23 – 30/9/2017

Actual submission date: 30/6/2017

Start date of project: 01/10/2014

Work package/Task WP3/ Task 3.1 - T3.1 Master Planning

Lead Beneficiary European Space Agency

Lead Author Gianfranco Visentin

Authors Daniel Noelke, Michel Delpech, Sabine Moreno, Roberto Bertacin, Javier Rodriguez, Daniel Jones

Status Final

Dissemination Level Public

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 640026

This document reflects only the Consortium’s view. The EC/REA are not responsible for any use that may be made of the information it contains.

/73


Date 25/10/2017 Issue 1.6

Title D3.2-Compendium of SRC activities (for call 2)

Issue 1.6

Author Gianfranco Visentin et al. Date 03/11/2017

Approved by Gianfranco Visentin Date 03/11/2017

Reason for change Issue Date

Initial release (skeleton) 0.1 22/05/2017

Main products and deliverables define 0.2 7/06/2017

Work logic and milestones 0.3 13/06/2017

Detailing 0.4 30/06/2017

Detailing 0.5 2/07/2017

Detailing 1.0 13/09/2017

Detailing 1.1 19/09/2017

Harmonisation 1.2 20/09/2017




Formatting 1.6 21/10/2017

Issue 1.6

Reason for change Date Pages Paragraph(s)

Fixing of inconsistencies and formatting 03/11/2017 all all

/73


Date 25/10/2017 Issue 1.6

Table of Contents

Applicable Documents................................................................................................................ 7

REFERENCE Documents .............................................................................................................. 7

Acronyms and Definitions .......................................................................................................... 8

1 Introduction ...................................................................................................................... 9 1.1 Objectives of the document ............................................................................................................................................ 9

2 Topic of the 2018 Call ......................................................................................................... 9 2.1 General Challenge ............................................................................................................................................................... 9 2.2 Application: Orbital Support Service (OG7) ............................................................................................................ 9 2.3 Application: Robotised Assembly Of Large Modular Orbital Structures (OG8) ....................................... 9 2.4 Application: Robotised Reconfiguration Of Satellites (OG9) .......................................................................... 10 2.5 Application: Autonomous Decision Making (OG10) in very long traverses ............................................ 10 2.6 Application: Exploring Robot-Robot Interaction (OG11) in planetary exploration and exploitation 10

3 Reuse of common building blocks .................................................................................... 11 3.1 Maintenance of Call 1 Building Blocks ..................................................................................................................... 12

4 Common Work Logic in the Operational Grants ................................................................ 14

5 Research Work and Deliverable Descriptions for THE Orbital support services (OG7) ........ 15 5.1 Objectives ............................................................................................................................................................................ 15 5.2 Work description .............................................................................................................................................................. 15

5.2.1 Definitions and System Breakdown ........................................................................................................................... 16 5.2.2 Description of Operations .............................................................................................................................................. 17 5.2.3 Reuse of Call 1 building blocks ..................................................................................................................................... 18

5.3 Work Logic .......................................................................................................................................................................... 20 5.4 Task Descriptions ............................................................................................................................................................. 20

5.4.1 Task 0: Technical management .................................................................................................................................. 20 5.4.2 Task 1: Technology Review, System Requirements ............................................................................................ 20 5.4.3 Task 2: Preliminary Design and Modelling ............................................................................................................ 21 5.4.4 Task 3: Detailed Design of Demonstrator and related test setup ................................................................ 21 5.4.5 Task 4: Manufacturing, Assembly and Integration of demonstrator and test equipment .............. 21 5.4.6 Task 5: Execution of test, demonstration and correlation of test results ................................................ 22

5.5 Programmatics .................................................................................................................................................................. 22 5.5.1 Schedule .................................................................................................................................................................................. 22 5.5.2 Duration ................................................................................................................................................................................. 22 5.5.3 Management ........................................................................................................................................................................ 22 5.5.4 Reporting ............................................................................................................................................................................... 22 5.5.5 Milestones and Meetings ................................................................................................................................................. 23

5.6 Deliverables ........................................................................................................................................................................ 23 5.6.1 General .................................................................................................................................................................................... 23 5.6.2 Documentation .................................................................................................................................................................... 23 5.6.3 Hardware and Software Deliverables ...................................................................................................................... 24

5.7 ANNEX 1 –USER Requirements .................................................................................................................................. 24 5.7.1 Functional Requirements ............................................................................................................................................... 24

/73


Date 25/10/2017 Issue 1.6

5.7.2 Implementation Requirements .................................................................................................................................... 24

6 Research Work and Deliverable Descriptions for the robotised assembly of large modular orbital structures (OG8) ............................................................................................................ 26 6.1 Objectives ............................................................................................................................................................................ 26 6.2 Work Description ............................................................................................................................................................. 27

6.2.1 Definitions and System Breakdown ........................................................................................................................... 28 6.2.2 Reuse of Call 1 Building Blocks .................................................................................................................................... 29


6.4.1 Task 0: Technical management .................................................................................................................................. 30 6.4.2 Task 1: Technology Review, System Requirements ............................................................................................ 30 6.4.3 Task 2: Preliminary Design and Modelling ............................................................................................................ 31 6.4.4 Task 3: Detailed Design of Demonstrator and related test Setup ............................................................... 31 6.4.5 Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment .............................................................................................................................................................................................. 31 6.4.6 Task 5: Execution of test, demonstration and correlation of test results ................................................ 32



6.7 ANNEX 2 –USER Requirements .................................................................................................................................. 34 6.7.1 Definitions and Product Tree........................................................................................................................................ 34 6.7.2 Functional Requirements ............................................................................................................................................... 36 6.7.3 Implementation Requirements .................................................................................................................................... 36

7 Research Work and Deliverable Descriptions for the robotised reconfiguration of satellites (OG9) ....................................................................................................................................... 37 7.1 Scope ...................................................................................................................................................................................... 37 7.2 Work description .............................................................................................................................................................. 38

7.2.1 Definitions and System Breakdown ........................................................................................................................... 38 7.2.2 Description of Operations .............................................................................................................................................. 40 7.2.3 Reuse of Call 1 building blocks ..................................................................................................................................... 40


7.4.1 Task 0: Technical management .................................................................................................................................. 42 7.4.2 Task 1: Technology Review, System Requirements ............................................................................................ 42 7.4.3 Task 2: Preliminary Design and Modelling ............................................................................................................ 43 7.4.4 Task 3: Detailed design of Demonstrator and related test setup ................................................................ 43 7.4.5 Task 4: Manufacturing, Assembly and Integration of demonstration and test equipment ............ 43 7.4.6 Task 5: Execution of test, demonstration and correlation of test results ................................................ 44

7.5 Programmatics .................................................................................................................................................................. 44 7.5.1 Schedule .................................................................................................................................................................................. 44

/73


Date 25/10/2017 Issue 1.6

7.5.2 Duration ................................................................................................................................................................................. 44 7.5.3 Management ........................................................................................................................................................................ 44 7.5.4 Reporting ............................................................................................................................................................................... 45 7.5.5 Milestones and Meetings ................................................................................................................................................. 45


7.7 ANNEX - User Requirements ....................................................................................................................................... 46 7.7.1 Functional Requirements ............................................................................................................................................... 46 7.7.2 Implementation requirements ..................................................................................................................................... 47 7.7.3 Verification requirements .............................................................................................................................................. 47

8 Research Work and Deliverable Descriptions for the autonomous decision making (OG10) 48 8.1 Objectives ............................................................................................................................................................................ 48 8.2 Work description .............................................................................................................................................................. 49

8.2.1 Assumptions to be considered for the study .......................................................................................................... 50 8.2.2 Reuse of Call 1 building blocks ..................................................................................................................................... 50


8.4.1 Task 0: Technical management .................................................................................................................................. 52 8.4.2 Task 1: Technology Review, System Requirements ............................................................................................ 52 8.4.3 Task 2: Preliminary Design and Modelling ............................................................................................................ 53 8.4.4 Task 3: Detailed design of Demonstrator and related test setup ................................................................ 53 8.4.5 Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment .............................................................................................................................................................................................. 53 8.4.6 Task 5: Execution of test, demonstration and correlation of test results. ............................................... 54



8.7 ANNEX 4 – USER Requirements ................................................................................................................................. 56 8.7.1 Definitions and Deliverable Tree ................................................................................................................................ 56 8.7.2 Functional requirements: ............................................................................................................................................... 57 8.7.3 Verification requirements .............................................................................................................................................. 58 8.7.4 Implementation requirements: .................................................................................................................................... 59

9 Research Work and Deliverable Descriptions for the exploring robot-robot interaction (OG11) ..................................................................................................................................... 60 9.1 Objectives ............................................................................................................................................................................ 60 9.2 Work description .............................................................................................................................................................. 62

9.2.1 Definitions and system Breakdown ........................................................................................................................... 62

/73


Date 25/10/2017 Issue 1.6

9.2.2 Description of Operations .............................................................................................................................................. 64 9.2.3 Reuse of Call 1 building blocks ..................................................................................................................................... 65


9.4.1 Task 0: Technical management .................................................................................................................................. 66 9.4.2 Task 1: Technology Review, System Requirements ............................................................................................ 66 9.4.3 Task 2: Preliminary Design and Modelling ............................................................................................................ 67 9.4.4 Task 3: Detailed design of Demonstrator and related test setup ................................................................ 67 9.4.5 Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment .............................................................................................................................................................................................. 68 9.4.6 Task 5: Execution of test, demonstration and correlation of test results ................................................ 68



9.7 ANNEX 5 –USER Requirements .................................................................................................................................. 70 9.7.1 Functional Requirements ............................................................................................................................................... 70 9.7.1 Implementation Requirements .................................................................................................................................... 71 9.7.2 Verification Requirements ............................................................................................................................................. 72

/73


Date 31/10/2017 11:13:00 Issue 1.6

APPLICABLE DOCUMENTS

Source Document Link OG1 Design Definition Document www.h2020-peraspera.eu Interface Control Document www.h2020-peraspera.eu OG2 Design Definition Document www.h2020-peraspera.eu Interface Control Document www.h2020-peraspera.eu OG3 Design Definition Document www.h2020-peraspera.eu Interface Control Document www.h2020-peraspera.eu OG4 Design Definition Document www.h2020-peraspera.eu Interface Control Document www.h2020-peraspera.eu OG5 Design Definition Document www.h2020-peraspera.eu Interface Control Document www.h2020-peraspera.eu

PSA Integrated Interface Control Document

www.h2020-peraspera.eu

SRC Roadmap www.h2020-peraspera.eu EC Call Text EC Participant portal

REFERENCE DOCUMENTS

Source Document Link ESA ASSIST Standardisation File

Document www.h2020-peraspera.eu

/73


Date 25/10/2017 Issue 1.6

ACRONYMS AND DEFINITIONS

APM Active Payload Module

ASM Active System Module

AURA Association of Universities for Research in Astronomy

CDR Critical design Review

dRAS demonstrator Robotic Assembly System

dSMT demonstrator Segmented Mirror Tiles

ERGO EUROPEAN ROBOTIC GOAL-ORIENTED autonomous controller (OG2 in the SRC)

ESROCOS EUROPEAN SPACE ROBOTICS CONTROL AND OPERATING SYSTEM (OG1 in the SRC)

InFuse Infusing Data Fusion in Space Robotics (OG3 in the SRC)

H2020 Horizon 2020

ICU Interface Control Unit

I3DS Integrated 3D sensors (OG4 in the SRC)

ISRU In-Situ Resource Utilization

OBC On-Board Computer

OGxx Operational Grant with xx [1-6] belonging to the call 2015 and xx [7-11] belonging to acall 2017

ORUs Orbital Replaceable Unit(s)

OSS Orbital Support Servicies

PDR Preliminary design Review

RAS Robotic Assembly System

RdV Rendezvous

RRI Robot-Robot Interaction

SIROM Standard Interface for Robotic Manipulation of Payloads in Future Space Missions (OG5 in the SRC)

SMT Segmented Mirror Tiles

SRC Strategic Research Cluster

SRR System Requirements Review

TRR Test readiness review

/73


Date 25/10/2017 Issue 1.6

1 INTRODUCTION

1.1 Objectives of the document

This document constitutes the Technical Annex to the 2018 Call for the EC H2020 Strategic Research Cluster (SRC) in

Space Robotics Technologies.

The document contains the detailed description of work, in terms of dependency on previous SRC activities, goals,

achievements, programmatic aspects and the detailed specification of deliverables for each of the Operational Grants to

be awarded in the call.

2 TOPIC OF THE 2018 CALL

2.1 General Challenge

The overall challenge of this strategic research cluster (SRC) is to enable major advances in space robotic technologies for

future on-orbit missions (robotics and proximity rendezvous), and the exploration of the surfaces of the other bodies in

our solar system.

The first activities in the SRC (2016 Call) have addressed designing, manufacturing and testing of reliable and high-

performance common robotic building blocks for operation in space environments (orbital and/or planetary), which will

be used for the activities subject to this call.

The specific objective of this 2018 call is to integrate the previously prepared common building blocks into

demonstrators, on ground, towards applications of space robotics in the field of orbital and planetary use (phase 0/A

studies). These robotics applications address not only the future needs of exploration and exploitation of space but also

potential spin-off and spill-over effects to other areas of robotic activity on Earth, such as agricultural, automotive,

mining, nuclear, or underwater.

The applications and activities selected for the second call contain enabling elements for enhancing and fostering

commercialisation of space considering aspects of New Space and Industry 4.0.

2.2 Application: Orbital Support Service (OG7)

The aim of OG7 is to demonstrate the techniques needed to offer a commercial service to operational satellites. This shall

as minimum address robotic deployment and refuelling of satellites in orbit. By means of a general purpose robotic arm, a

servicing satellite must be capable to demonstrate release, grasping, berthing and manipulation of a target satellite

including services such as refuelling.

The outcome sought in OG7 is the functional demonstration in a ground based simulation facility, of applications of space

robotics in the field of orbital servicing. The basic operations that have to be covered are: rendezvous, berthing, refuelling,

ORUs replacement and SW upgrade.

2.3 Application: Robotised Assembly Of Large Modular Orbital Structures (OG8)

The aim of OG8 is to demonstrate the techniques needed to robotically assemble a large structure on-orbit, comprised of

tessellated, hexagonal tiles, which would otherwise not be feasible with a single launch.

The outcome sought is the demonstration, in an orbital simulation facility on earth, of a Robot Assembly System, related

Mounted Mobility System, Tiles and assembly techniques. The overall system must demonstrate the ability to deploy

itself from the spacecraft bus, remove individual tiles from their launch configuration, and attach them together in

accordance with a prepared plan or schematic of the final mirror design. Each of the tiles must be individually

controllable once assembled so as to achieve the optimum optical design.

/73


Date 25/10/2017 Issue 1.6

2.4 Application: Robotised Reconfiguration Of Satellites (OG9)

The aim of OG9 is to demonstrate the techniques needed to realise a satellite-mounted robot system and its related

implements that can modify the functionality of a satellite by adding/replacing modules available on-board or provided

by another servicing satellite.

The outcome sought in OG9 is the successful demonstration, in a ground based simulation facility, of robotised

reconfiguration of a satellite model. Specifically the reconfiguration (hardware/software) of a highly-modular,

maintainable, extendable satellite system according to a defined and simulated plan as well as manipulation of functional

modules -which are coupled via a standard interconnector- on the satellite platform by a satellite-mounted robot.

2.5 Application: Autonomous Decision Making (OG10) in very long traverses

The aim of OG10 is to demonstrate the techniques needed for realising a planetary rover system with very long traverse

capabilities (kilometres a day) by independently taking the decisions required to progress, reduce risks and seize

opportunities. Such a rover system will be required to travel independently from a starting point (e.g. a lander) towards

and end point (say a cache of sample), perform independent opportunistic science on the way and return to the lander

with the acquired soil sample.

The outcome sought in OG10 is the demonstration of such capabilities in a terrestrial analog of a planetary environment.

2.6 Application: Exploring Robot-Robot Interaction (OG11) in planetary exploration and exploitation

OG11 aims at exploring the potential of robot-robot interaction, in two alternative planetary applications:

Exploration of difficult sites: a suite of robots endowed with diverse mobility that can cooperate autonomously in

the exploration of very hard-to-reach navigate planetary areas. This team of robots will be entrusted to

undertake multiple descents and ascents into a crater/gully performing coordinated mapping and science.

Robotised construction: a team of specialised robots with multiple robotic arms and end-effectors that, through

a minimum of drilling, excavating and manipulating, can cooperatively put together a future planetary

base/ISRU plant.

The outcome sought in OG11 is the successful demonstration, in a ground based facility (lunar or Martian analogue), of

cooperative robots in operations such as joint exploration, underground survey, foundation laying and structural

elements assembly needed for base construction.

/73


Date 25/10/2017 Issue 1.6

3 REUSE OF COMMON BUILDING BLOCKS

Figure 1: Overview of how the outputs of the OGs of the first Call of the space robotics technology cluster, integrate within the space robotics applications developed by the OGs of the second call. Left: OG1-5 provide the core capabilities of a robot system while OG7-11 provide the platforms and interaction with the application environment. Right: the outputs of OGs will be integrated into 2 types of applications, the ones addressing orbital robotics (OG7-9) and the ones addressing planetary robotics (OG10-11).

The two alternative views in Figure 1 display how the outputs of the OGs of the first Call of the space robotics technology

cluster, integrate within the space robotics applications developed by the OGs of the second call.

In the “sense-plan-react cycle” view (left in Figure 1) it can be seen that the output of OG1, the Robot Control Operating

System (RCOS) is at the centre and base of all other software elements. The products of OG1, with OG2, the plan-and-

react function, and of OG3, the “sense” function, are intended to be used in creating the software implementing the

application control. The products of OG4, a suite of perception means, and of OG 5, making generic physical interfaces

for manipulation, will complement the hardware produced by OG7-11.

In the right of Figure 1 the 2 types of applications, the ones addressing orbital robotics (OG7-9) and the ones addressing

planetary robotics (OG10-11) will integrate the OG1-5 products as shown.

The precise level of integration of each of Call-1 products is addressed in the description of work and deliverable of each

OG7-11. The common building blocks have been designed and are produced to serve diverse space applications. It is

however clear that in the course of execution of OG7-11 upgrades may be needed to serve the specifics of the applications

subjects of OG7-11.

In order to guaranty the equality of proposals from all bidding consortia, it is foreseen that:

all consortia bidding for OG7-11 will all be able to access the preliminary design documentation (i.e. Preliminary

Design Document and ICD) for the ESROCOS, ERGO, InFuse, I3DS and SIROM projects.

Critical Design Documents will be made available in time for the Grant Agreement Preparation (GAP) of OG7-11

Licences for the relevant products will be legally established in time for the Kick Off for OG7-11

Licences, full system and test designs will be available for project Kick-Off

/73


Date 25/10/2017 Issue 1.6

In the case of the I3DS and SIROM not only software and designs have been produced but also some hardware has been

manufactured/procured. This hardware shall also be reused in the OGs of the second call.

The number hardware units produced/procured in the OGs of Call 1 will not be sufficient to cover the needs of the Call2

OGs.

So this document defines which OGs will receive the existing hardware, as well as which OGs are expected to

reproduce/procure new units.

3.1 Maintenance of Call 1 Building Blocks

The primary goal of OG7-11 is to implement demonstrators of their target space robotics applications.

In order to realise this goal, it may be necessary to upgrade the software and hardware suites developed as Common

Building Blocks to suit the specific applications required.

The strength of Common Building Blocks is in that they are and remain common. The legal basis for commonality is in

the provisions of Article 4.2 and 4.4 of the “Collaboration Agreement” of the Space Robotics Strategic Research Cluster.

Practically, to maintain the commonality across the SRC developments, an effort of the SRC members during Call 2 is

required.

That being the case, it is incumbent upon all the consortia within OG7-11 to share the responsibility of the Common

Building Blocks, by:

1) Improve and enhance the Common Building Blocks in general and specifically for the applications target of the

call

2) fully justifying any changes, to avoid proliferation of changes

3) ensuring that any developments undertaken are centrally managed and integrated into a Master Version of the

Common Building Block product.

In the case of 1) and 2) all consortia are expected to provide the bug fixes and usability improvements of the common

building blocks they need to use.

Specifically, for 3) each consortium shall assign one member (Product Maintainer) to be responsible for managing a

specific Common Building Block (indicated in the rest of this document), and ensuring that any fixes and additional

capabilities are effectively integrated into the central software / hardware, creating new and updated versions of the

product that will then be re-disseminated to all users (among all OGs) as appropriate.

The figure of the Product Maintainer in this call is similar to the role of a Package maintainer in open source software

projects, having similar responsibilities and tasks.

The Product Maintainer shall manage this through the custodianship of a GIT repository that will contain all versions.

The Product Maintainer will also be responsible for archiving and integrating any addendum documentation generated

across the SRC, such as user guides, test data, and troubleshooting solutions.

There are five common building block products, and five application OGs; each new OG shall be responsible for the

central maintenance of one of the Common Building Block products listed in Table 1 .

Call2 OGs Call1 OGs

OG7 OG4

OG8 OG5

OG9 OG1

OG10 OG2

OG11 OG3 Table 1 Product maintenance responsibility

In short, the Product Maintainer must:

Maintain an online repository where all relevant software and hardware developments must be securely kept

Be the point of contact for disseminating and receiving new code, addendums and features of the common

building block

Integrate any changes or new features with the central version covering generic and specific evolvements of the

common building blocks

Ensure any changes in functionality are captured in the user guidelines to help with use, troubleshooting, etc.

http://www.h2020-peraspera.eu/wp-content/uploads/2015/12/Collaboration-Agreement-Space-Robotics-Technologies-SRC.pdf

/73


Date 25/10/2017 Issue 1.6

Example

The Robot Control Operating System (ESROCOS) will need to be used in different ways for OG7, OG8, OG9 etc.

In the process of using ESROCOS all OGs will fix some issues and make additions to the initial version of ESROCOS.

All these changes will be provided to the ESROCOS Product Maintainer (in this case OG9 is responsible for the

maintenance of OG1) who will merge the changes and integrate in the master version of the software package which

will then be re-circulated to all users.

/73


Date 25/10/2017 Issue 1.6

4 COMMON WORK LOGIC IN THE OPERATIONAL GRANTS

The work logic of all OGs shall be the same and follow Figure 2. The diagram shows the integrated flow from technology review and system requirements up to the final acceptance of the developed technologies. For each OG a separate schedule is defined and described in the corresponding chapter.

Figure 2 Basic work logic for all OGs

/73


Date 25/10/2017 Issue 1.6

5 RESEARCH WORK AND DELIVERABLE DESCRIPTIONS FOR THE ORBITAL SUPPORT SERVICES (OG7)

5.1 Objectives

The vision for satellite servicing is straightforward: to refuel, repair or upgrade satellites after they are launched. Most

satellites are expensive pieces of hardware that still have much utility after some critical resource has been expended or

some critical technology has become obsolete. Sending a servicing spacecraft to repair or replace a broken critical

component, refill the tanks or move the satellite into another orbit will produce life extension and additional utility from

what would have become a debris.

In the last decades, several proposals to construct satellites that could be re-fuelled or re-furbished in space have been put

forward by several space actors. However, these proposals were dismissed on the fear that the provisions needed on a

serviceable satellite made it more complex, heavier and hence more expensive, than a disposable one.

Besides that, in the past servicing could not bring sensible advantages to satellites, mainly due to the fact that satellites

were built without taking into account the serviceability. Nowadays, the advances in technology, trends in size and weight

of commercial satellites as well as the increased standardization (due to the reduction of satellite manufacturers) have

changed these past considerations. A satellite-servicing infrastructure together with the possibility to designing satellites

including serviceability standards, and the necessity of increased flexibility in satellites, will benefit the future of on-orbit

servicing, in the next generation of satellites and improve the competitiveness of European industry.

Satellite servicing is one of the “master enabler” for the new space architectures and next generation of satellites.

Nowadays, satellite systems may be the only complex system without a routine maintenance, repair or upgrade program,

and sector is waiting until these technologies are validated in a demonstrator, to allow for orbital support services as a

business case for the next generation of satellites.

Robotics technologies are the only systems that will allow efficient servicing of space infrastructure. As an example, Robot

manipulators are flexible means and can, with the necessary standardisation and through the use of different end

effectors, implement most of the operations that are envisaged in servicing an space infrastructure; these operations

include many aspects of assembly and manipulation of equipment (both corrective and preventive), replenishment of

consumables and upgrade and repair capabilities.

The challenge of this OG is to demonstrate the techniques needed to offer support and maintenance services to

operational satellites. These maintenance services will be provided by an Orbital Support Services (OSS) spacecraft that,

by berthing to a client satellite, can perform a variety of servicing tasks, including installation & replacement of hardware,

refuelling of propellant, upgrade and lifetime extensions.

The OSS and the client spacecraft will be designed to allow servicing tasks. Specifically:

The OSS spacecraft is made of a spacecraft platform fitted with a servicing payload (which will include at least

one general purpose robotic arm)

The client satellite includes specific servicing provisions: grapple fixtures, guidance aids, latching mechanism etc

Both spacecraft have compatible interfaces for grasping/refuelling and for ORUs (Orbit Replaceable Units)

exchange (allowing mechanical, data, electrical, thermal interfacing) stemming from previous work in the SRC

(SIROM interconnects for ORUs) and possibly ESA activities (e.g. the ASSIST gripper/refuelling interface).

The final objective of this OG is to demonstrate the techniques, the elementary operations and finally the

top-level orbital support services in an orbital simulation facility.

5.2 Work description

The demonstration involves two spacecraft: one servicing satellite (the OSS) and one client satellite to be serviced, both of

them designed with the provisions for the servicing operations.

The demonstration scenario will consist in the autonomous rendezvous manoeuvres and berthing between both satellites

using the robotic arm of the OSS spacecraft, with a specific end-effector, and the grasping fixture of the client satellite.

Once the client spacecraft is captured, the robotic arm berth the two spacecraft, i.e. will bring closer the client spacecraft

with the objective to dock the launcher adaptor of the client satellite with a locking mechanism located in one of the sides

/73


Date 25/10/2017 Issue 1.6

of the OSS satellite. Once the mechanical stiffness between both spacecraft is ensured, the robotic arm could be released

from the grasping fixtures and begin the servicing operations.

The basic operations that shall be addressed by this OG are: satellite refuelling with the objective to extend life and reduce

initial launch wet mass; satellite repair of existing subsystems to restore mission operability or replace failed components

and upgrade/enhancement of critical technology/payload that has become obsolete.

After servicing of the client satellite and check that the status of both spacecraft is correct, the locking system will be

released and both vehicles will be decoupled (either by robot arm or by the action of their thrusters).

To achieve such demonstration, the work in the OG shall:

Design the servicing payload

Define and standardize the necessary servicing provisions for client satellites

Develop the techniques and elementary operations

Implement servicing payload, and satellite provisions in a demonstration set-up to be used in the orbital

simulation facility

The challenge of this scenario lies in:

Integrating the common building blocks of Call1

Enhancing their TRLs

incorporating additional elements such as refuelling interfaces, into the demanded orbital support servicing

applications.

An end-to-end demonstration shall be carried out in a robotic orbital test bench of the servicing scenario. Whenever

possible, existing standards (SIROM, ASSIST, etc) shall be re-used to maximise possible future commercial exploitation

of the results of the activities.

5.2.1 Definitions and System Breakdown

The full application scenario assumed in the orbital support services (OG7), sees at least, two spacecraft: a client satellite

and an OSS spacecraft. The following breakdown describes the salient elements of these two spacecraft and the complete

scenario:

OSS spacecraft:

Platform

Servicing payload

o Stock of ORUs

New ORU/APM to be installed in serviced satellite with SIROM interconnect

o Refuelling subsystem

Tank and piping

Grasping/refuelling tool possibly based on ESA activities (e.g. the ASSIST gripper/refuelling

interface) and equipped with a SIROM interconnect.

o Robotic subsystem

At least one 6DoF manipulator equipped with a SIROM interconnect

a multi-purpose On-Board Computer (OBC) equipped with the ESROCOS Robot Control

Operating System (RCOS)

the robotic autonomous control software based on the ERGO and InFuse, that take decisions

on the servicing operations and that is capable of RdV and berthing using visual navigation &

servoing.

a sensor suite equipped with all necessary sensors to fulfil its purpose, based on I3DS

Client satellite:

o Platform and payload

o Replaceable subsystems

ORUs/APMs equipped with SIROM interconnects

o Grasping/Refuelling Provisions

• Mechanical interface for the berthing operation (connector & grasping fixture)

• Markers to facilitate RdV and berthing

• Alignment aids

/73


Date 25/10/2017 Issue 1.6

• Latching and locking mechanism (implemented between launcher adaptor of client satellite &

OSS satellite)

• A refuelling interface with piping connecting it to a refillable tank.

In this OG is neither possible nor necessary that the demonstrator implements all the elements of the full application

scenario: this demonstrator shall address only those parts that are essential to the validation of the techniques, the

elementary operations and finally the top-level orbital support services.

Therefore, the demonstrator of this OG shall consist of:

OSS spacecraft:

Platform: The platform shall be replaced by a geometric mock-up

Servicing payload

o Stock of ORUs

One APM to be installed in serviced satellite with SIROM interconnect

o Refuelling subsystem

Tank and piping

Grasping/refuelling tool (mountable as manipulator end-effector using SIROM interconnect)

Latching & locking mechanism between mock-ups.

o Robotic subsystem

A 6DoF manipulator equipped with a SIROM interconnect and end-effector

a multi-purpose On-Board Computer (OBC) equipped with the ESROCOS Robot Control

Operating System (RCOS)

The robotic autonomous control software based on the ERGO and InFuse, that take decisions

on the servicing operations and that is capable of RdV and berthing using visual navigation &

servoing.


Client satellite:

Platform and payload: shall be replaced by a geometric mock-up

o Replaceable subsystems

One APM equipped with 2 SIROM interconnects

o Grasping/Refuelling Provisions

Mechanical interface for the berthing operation

Markers to facilitate RdV and berthing

Latching & locking mechanism provisions

A refuelling interface with piping connecting it to a refillable tank.

The demonstration shall take place in a space representative (i.e. illumination conditions, achievable accuracies) robotic

orbital facility, such as the ones that are being used in OG6, using the breadboard prepared.

5.2.2 Description of Operations

The system to be designed and developed shall at least support the following set of capabilities and operations:

The OSS satellite shall be able to perform the autonomous short range RdV and capture manoeuvres (using the

manipulator and grapple fixtures)

Data transfer between Operational and OOS satellite to confirm correct capture

The OSS satellite shall be able to perform berthing according to the following sequence:

o Move the client satellite (launch adaptor side) to the docking site of the OSS satellite

o Latching & locking of the OSS satellite with the client satellite using the launcher adaptor of the client

satellite

o Release the manipulator of the mechanical fixtures and prepare the OSS satellite for the servicing

operations.

/73


Date 25/10/2017 Issue 1.6

Figure 3: Spacecrafts (OSS satellite left side and client satellite right side) during berthing manoeuvres (left) & satellites locked using the launch adaptor of the client satellite (centre) and satellites locked executing servicing operations with the manipulator (right)

Start servicing operations:

o The OSS satellite shall be able to realise the refuelling operation of the empty tanks

o The OSS satellite shall be able to replace a failed ORU

o The OSS satellite shall be able to monitor the status of the parameters (load, temperature, data, power

o etc.)

Figure 4: satellites before servicing (left) & post servicing operations (right)

The proposed orbital support services demonstration includes the following phases:

Rendezvous final phase: from ~20 meters to 1 meter (capture distance).

Capture phase: operated by the robotic arm to mate the servicing end-effector with the counter part of the

serviced satellite.

Berthing, latching & locking the OSS satellite with the launcher adaptor of the client satellite (as example). Once

the mechanical stiffness of the locking mechanism is ensured, the system will prepare the OSS satellite for the

servicing operations

Servicing phase: Composed by the refuelling operation, replacement of the failed HW unit & continual check of

the status of the serviced satellite and control parameters of the manoeuvres, and upgrade of the OBSW of the

serviced satellite.

De-mating phase: the servicing operations have been concluded, the docking mechanism unlocks and both

satellites decouple.

5.2.3 Reuse of Call 1 building blocks

The use, development and integration of the five Common Building Blocks being currently developed by OG1-5 in Call 1 of

the SRC is mandatory for OG7. The Common Building Blocks must be integrated into orbital support services application.

/73


Date 25/10/2017 Issue 1.6

5.2.3.1 ESROCOS

The ESROCOS system shall be used as the core operating system for the OSS scenario. ESROCOS shall be used in the

following capacity:

To create a suite of robot controllers able to execute the robot control applications required by the task

To develop, test, maintain and validate those robot control applications created

To configure the middleware that will enable control of the robot applications required for this task

5.2.3.2 ERGO

The ERGO Controller shall be used and configured so that the OSS satellite execute the manoeuvres of close RdV,

berthing, locking and the servicing operations. This entails:

Executing the mission in its phases

Managing execution of the ground commands

Planning and executing the RdV

The planning and control of the robot arm

Path and trajectory planning and execution of the robot arm

Planning and control of the robot arm end-effector

Collision monitoring and prevention

Control the SIROM connectors to achieve coupling/uncoupling

5.2.3.3 InFuse

The InFuse Common Data Fusion Framework shall be used to model the environment, and estimate satellites states and

relative positions, in order to assist the OSS decision making and planning with respect to guidance, navigation and

control. This entails:

To fuse information of all sensors

To estimate relative pose and rates of the two satellites

To model geometries to support collisions monitoring and prevention

To request particular images or data from specific sensors

5.2.3.4 I3DS

The I3DS Sensor Suite is instrumental for the OSS scenario to achieve its goal of RdV, berthing, locking & servicing

operations. The sensor suite shall:

perform centralisation and pre-processing of sensor data output

Provide information to the autonomous controller and data fusion framework needed to make decisions with

respect to:

o Manipulation (Approach, grasp, latch, connect)

o Mobility (movement, attitude, state, localisation)

OG7 is designated to receive the hardware items produced/procured by I3DS at the completion of OG4.

OG7 shall also be the Product Maintainer of the I3DS products.

5.2.3.5 SIROM Interface

The SIROM interconnector shall be used as the hardware interface and between couplings points, the SIROM Connector

shall also be used as the point of interface upon the robot itself. The SIROM connector then shall:

Be used to interconnect the end-effector with the manipulator

To interconnect and interface for the APMs

Enable interface and exchange of thermal, electrical, data and mechanical loads and flux

OG7 is expected to reproduce/procure all SIROM interconnects needed for the work in OG7.

/73


Date 25/10/2017 Issue 1.6

5.3 Work Logic

The work logic is the same for all Operational Grants, it is defined in chapter 4. The diagram in the chapter shows the integrated flow from technology review and system requirements up to the final acceptance of the application and technology development.

5.4 Task Descriptions

5.4.1 Task 0: Technical management

This task deals with the administrative, technical, and financial management of the project. This includes reporting

(financial and technical) and coordination with the EU, quality assurance, risk assessment, monitoring, administration

and re-planning of resources, and timely provision of deliverables.

The task deals also with the coordination:

among Consortium participants, technically by providing communication and collaboration tools, and

relationally by facilitating project communications and conflict resolution

with other Consortia recipient of Operational Grants in the SRC

with the Programme Support Activity of the SRC

The activities related to the coordination within and outside the Consortium are detailed in § 5.5

5.4.1.1 Task 0.1: Maintenance of Call 1 Building Blocks

The generic needs and deriving activities for maintenance of Call1 Building Blocks are describe at §3.1

OG7 shall be responsible for the central maintenance of OG4 I3DS sensor suite. This means OG7 shall:

Maintain an online repository where all relevant software and hardware developments must be securely kept

Be the point of contact for disseminating and receiving new code, addendums and features of the I3DS sensor

suite

Integrate changes or new features with the central version


5.4.2 Task 1: Technology Review, System Requirements

The initial part of this task is a Technology Review in the field of orbital servicing & refuelling.

The Technology Review shall assess the state-of-the-art as well as the products being developed by OG1-5

The review shall address differing potential methods of achieving the overarching objective of OG7, so that the pros and

cons of each method may be properly understood.

With respect the products being developed by OG1-5, namely:

OG1 – The ESROCOS operating system

OG2 – The ERGO Controller

OG3 – The InFuse Data Fusion system

OG4 – The I3DS sensor suite

OG5 – The SIROM Interconnector for robotic manipulators

the review shall define how these products will be used, further developed or adapted to suit the task at hand

Following the technology survey, System Requirements shall be identified, in terms of:

functional requirements

performances requirements

mechanical requirements

electrical requirements

data requirements

S/W requirements

The System Requirements will be captured in a dedicated deliverable document, which is to be presented for review at the

SRR, as stated in §4.

/73


Date 25/10/2017 Issue 1.6

5.4.3 Task 2: Preliminary Design and Modelling

The System Requirements as described in §5.4.2 will form the basis for the preliminary design of the orbital support

services and refuelling System. Task 2 will therefore comprise the following actions:

Detail the architecture and elements of the application scenario, to the extent needed

Detail the demonstration tests to validate the application scenario, establish test procedures

Detail the architecture of the demonstration scenario and requirements with respect to equipment, facilities,

data, robotic software & hardware to enable a robust and comprehensive validation by demonstration

Describe in detail how the products developed by OG1-5 are going to be used, further developed or adapted to

suit this OG.

Identify existing any other components/systems additional to OG1-5 that may need to be used and hence

developed, procured or adapted to achieve the desired effect.

Define where features or technology may have to be developed from scratch to complement or augment the

existing/mandated hardware and software systems

Define the steps required to develop and integrate this demonstration system

The Preliminary Design will be captured in a dedicated deliverable document, which is to be presented for review at the

PDR, as stated in §4.

5.4.4 Task 3: Detailed Design of Demonstrator and related test setup

The task shall include all activities needed to identify, define and design the elements allowing the demonstration of the

sought orbital support services.

At the end of this task it shall be possible to immediately initiate the manufacturing/coding/procurement, integration and

testing of the elements of the scenario demonstrator. Therefore the task shall at least include the following individual

activities:

Detail definition of the operations of RvD, capture berthing and refuelling/servicing

Detail definition of the demonstration tests, at least, the following tests shall be performed:

o test of close rendezvous, capture and berthing

o robotic servicing test (refuelling)

o robotic servicing test (ORUs replacement)

o decoupling test

Definition and Detail Design of the OSS spacecraft and subsystems

Definition and Detail Design of Client Satellite

Definition of test support equipment, identification of available items and design of missing items

Definition of the standardization needed during satellite design

The definition of the work required to adapt/develop the products developed in OG1-5

The results of the task shall be documented in a dedicated deliverable document and in a dedicated branch of the

GIT repository.

The Detailed Design is to be presented for review at the CDR, as stated in §4.

5.4.5 Task 4: Manufacturing, Assembly and Integration of demonstrator and test equipment

The task shall include all manufacturing/coding/procurement, integration and testing activities needed to produce the

demonstration of the sought orbital support services. This task takes as input the results of the CDR to provide the final,

integrated model of the demonstrator as fully functional representative of space scenario.

At the end of this task it shall be possible to immediately initiate the demonstration tests

Therefore the task shall at least include the following individual activities:

Procurement of items identified in the Detailed Design

Manufacturing of items identified in the Detailed Design

Coding of the required control software and test

Preparation of required support equipment

/73


Date 25/10/2017 Issue 1.6

Integration of hardware, software and required support equipment

Unit tests and tests of successful integration

Production of Manufacturing and User documentation (drawings, AIT plan, user/operational manual, S/W

documentation)

The demonstrator is to be presented for review at the TRR, as stated in §4.

Any documentation produced by the task shall be uploaded in the GIT repository.

5.4.6 Task 5: Execution of test, demonstration and correlation of test results

This task contains all activities pertaining to the execution of the demonstration test campaign, acquisition, processing

and analysis of data to validate the implementation of orbital support services or assess any non conformance.

The results of the task shall be documented in a dedicated deliverable document and in the GIT repository.

The task shall be concluded with a Final Acceptance (FA) and Demonstration Event, where results of the test campaign as

well as a complete orbital support servicing operation (from RvD to detach) are to be presented, as stated in §4.

5.5 Programmatics

5.5.1 Schedule

The OG will run according to the sequence of tasks stated at § 4.4 The OG is required to report periodically and present

the results during meetings and reviews (milestones) in certain time steps.

Some of the milestones of the OG are, however, in common for all the OGs in the SRC. The precise date of these common

milestones will be determined by the SRC Board, as established following the Collaboration Agreement.

5.5.2 Duration

The total duration of this Operational Grant is 24 months from the Kick-Off (T0).

5.5.3 Management

The consortium of the OG shall create a management plan listing all activities required under task 0.

The consortium of the OG has to perform all meetings defined in section 4. Meetings with other OG Consortia can be

organised asneeded.

For any meeting, the PSA consortium shall be invited.

All meetings shall be announced with an Agenda of the items to be discussed.

The Coordinator of the OG shall take minutes for each meeting.

The Coordinator shall maintain an Action-Items List so that all actions are tracked.

The Coordinator shall maintain an up-to-date schedule of the OG activities.

5.5.4 Reporting

The OG Consortium shall produce periodic reports on the status of work. For this OG it is required to submit every 3

months a progress report, that records:

the technical description and state of advancement of the work and results in the reference period;

updated schedule;

action item list;

the exploitation plan based on the results gained since -T0-;

the dissemination done in the reference period;

updated plan for the next 3 months.

The OG Consortium shall produce a final report being a complete description of the work done within the 24 months of

the Operational Grant.

The OG Consortium shall finally produce:

/73


Date 25/10/2017 Issue 1.6

a final dissemination report and

an exploitation plan

Each report has to be submitted in Microsoft Word (doc or docx) format. A copy in Adobe PDF format has to be added to

each submission.

Every presentation given within the Operational Grant has to be submitted in the Microsoft Powerpoint (PPT or PPTX)

format. A copy in Adobe PDF format has to be added to each submission.

5.5.5 Milestones and Meetings

The following Milestones are defined. The milestones are associated to reviews with the participation of the PSA:

Milestone Meeting Schedule

KO Kick-Off T0

SRR System Requirements review Tentatively T0+3 months

PDR Preliminary design review Tentatively T0+9 months

CDR Critical Design Review T0+15 months

TRR Test Readiness Review T0+22 months

FA Final Acceptance, Demonstration

Event and Final Presentation

T0+24 months

Table 2: Milestones required for OG7

The Consortium is expected to establish additional Progress Meetings, with the frequency of 1 every 2

months, when not in combination with Milestone events, open to the participation of the PSA.

5.6 Deliverables

5.6.1 General

The categories of access rights on deliverable product of this OG are listed in the Collaboration Agreement. The following

sections define for each deliverable the class of access rights.

5.6.2 Documentation

All documents must be delivered in draft format 10 working days ahead of the pertinent review and in final format

(integrating the amendments agreed in the review) 1 month after the review.

Table 3 lists the minimum set of documents that are required for the SRC following activities. It is assumed that other

technical documents will be generated (according ECSS for phase0/A study) to support the exchange of information

within the OG7 Consortium, these documents shall have CO-1 access rights.

/73


Date 25/10/2017 Issue 1.6

Table 3: Core deliverables required for OG7

5.6.3 Hardware and Software Deliverables

Under the provisions of Article 4.2 and 4.4 of the “Collaboration Agreement” of the Space Robotics Strategic Research

Cluster:

Any hardware procured or produced in the frame of the grant, shall be delivered to the PSA at the end of the

project duration for supporting the evolution of the technology in the next step in the SRC.

Any software produced in the frame of the grant, shall be delivered to the PSA at the end of the project duration

for supporting the evolution of the technology in the next step in the SRC.

5.7 ANNEX 1 –USER Requirements

5.7.1 Functional Requirements

The system to be designed, developed and demonstrated shall at least support the following set of capabilities/operations:

OG7-R01 Autonomous short range RdV and capture with a manipulator (presence of mechanical fixtures and

guidance aids on the client satellite).

OG7-R02 Berthing of the client satellite (including final verification by data transfer between the 2 satellites))

OG7-R03 Refuelling operation

OG7-R04 ORU replacement

OG7-R05 Capability to transfer mechanical loads, electrical signals and data as well as thermal flux and fuel

between the coupled satellites.

OG7-R06 Capability to monitor the operations and the status of the client satellite (load, temperature, data,

power etc.)

5.7.2 Implementation Requirements

In order to successfully implement all the necessary functionalities for the system (demonstrator) of the scenario defined

at hand, the following aspects have to be taken into account:

OG7-R07 The technologies/products of Call1 have to be used according to the definition in section §3

OG7-R08 OSS satellite shall mount at least one 6DoF manipulator equipped with a SIROM interconnect

OG7-R09 Servicing and client satellite shall include specific servicing provisions.

Deliverable When Access Rights

OG7-D1-System Requirement Document SRD SRR PU

OG7-D2-Preliminary Design Document (PDD) PDR PU

OG7-D3-Test/Demonstration Specification PDR PU

OG7-D4-Demonstration Procedures CDR PU

OG7-D5-Detailed Design Document DDD CDR PU

OG7-D6-Software manual FA PU

OG7-D7-Test/Demonstration Report FA PU

OG7-D8-Videos FA PU

OG7-D9-Datasets FA PU

OG7-D10-Publications FA PU

OG7-D11-Final report and Final Presentation FA, PU

OG7-D12- Technology development plan SRR, updated at CDR, finalised at

FA

CO-1

OG7-D13- Dissemination plan SRR, updated at CDR, finalised at

FA

PU

OG7-D14-Exploitation plan SRR, updated at CDR, finalised at

FA

CO-1

/73


Date 25/10/2017 Issue 1.6

OG7-R10 Interfaces for grasping/refuelling shall be implemented using previous work in the SRC (SIROM) and

possibly ESA activities (e.g. the ASSIST gripper/refuelling interface).

OG7-R11 interfaces for ORU exchange (APM) and end-effector for the manipulator implemented using SIROM

OG7-R12 The design and simulation software shall be able to catalogue system elements, configure and simulate

the system with all related robotic elements and tasks as well as create a robotic compatible servicing plan for

the satellite platform

OG7-R13 In order to implement the effective testing of the OG7 systems, suitable testing facilities, equipment

and locations must be identified.

/73


Date 25/10/2017 Issue 1.6

6 RESEARCH WORK AND DELIVERABLE DESCRIPTIONS FOR THE ROBOTISED ASSEMBLY OF LARGE MODULAR ORBITAL STRUCTURES (OG8)

6.1 Objectives

Large structures in space are an essential element for space exploration and exploitation. There is no doubt that in the

future large solar power plants will be needed for asteroid mining and for massive electric propulsion needed by

interplanetary spacecraft. However, we do not have to look that far ahead to see how large space structures will bring

scientific and economic benefits. But to realise these benefits, we will need robotic capability to assemble the structures

in-orbit, as future structures will be too large to launch into space as a single self-deploying piece.

Space provides the best environment to study space itself, and space telescopes have been continually developed and

launched into space to complement and enrich the data collected by ground telescopes.

Each generation of telescopes tops the previous one in performance. Performance for telescopes is connected to aperture,

which in turn is connected to the size of the primary mirror of the telescope. The ongoing increases in the size of the

primary mirror constitutes a great preoccupation for spacecraft designers, as initially the mirror needs to be packed into

the relatively compact volume of the launcher fairings. The James-Webb telescope is considered by many the last

telescope that can be launched in a single self-deploying piece. Future telescopes will be several times the size of the

James-Webb (see Figure 5 for escalation of telescope sizes) and will need alternative ways to go from the launch

configuration to the full-deployed state1.

1 L. D. Feinberg et al.,“Modular assembled space telescope,”Opt. Eng.52(9), 091802 (2013)

https://asd.gsfc.nasa.gov/luvoir/docs/tech/ModularTelescopePaper.pdf

/73


Date 25/10/2017 Issue 1.6

Figure 5: Image title Comparison of nominal sizes of primary mirrors of notable optical telescopes, by CMG Lee/CC-BY-SA-3.0, Wikimedia commons. Note the relative dimensions of the Hubble and James Webb telescopes w.r.t. to terrestrial ones.

The objective of this OG is to develop and test a demonstrator of a robotic system that is able to assemble five tessellated,

hexagonal tiles that comprise one section of an on-orbit telescope mirror. The robotic system shall use and, where

necessary, develop the products already being developed in OG1-5 of the SRC to achieve this objective.

6.2 Work Description

OG8 represents a challenge-led scenario to design and demonstrate an autonomous, mobile robot system containing a set

of functional modules that can be used to assemble a large structure, being a large optical reflector, otherwise not feasible

with a single launch. The entire system must be demonstrated to work within an orbital simulation facility.

In this scenario, it is assumed that a spacecraft is launched so that all the elements eventually making the primary mirror are packed in a tight configuration that uses all the space within the launcher fairings. The elements comprising the mirror are hexagonal tiles that have individually actuated mirrors. The tiles are assembled into the mirror shape by a Robotic Assembly System.

/73


Date 25/10/2017 Issue 1.6

Each tile is equipped with a number of the SIROM interconnects allowing interconnection of the tiles as well as their manipulation by a Robotic Assembly System. The tiles also allow the Robotic Assembly System to travel on them, so that it may reach the outer edges of the mirror to attach the tiles of the outer ring.

Once in orbit a Robotic Assembly System releases the individual modules from their launch configuration and position them so that they build together the primary mirror of the telescope as a wall of hexagonal bricks. After having laid the first proximate bricks the Robotic Assembly System will need to travel over these to attach the outer bricks.

Once in position the individual tiles can control the attitude of their optical face to realise the desired mirror design.

The OG shall validate the capabilities essential to the scenario, by building a demonstrator of them and testing it in an orbital simulation facility.

The capabilities shall consider how the constituent parts of present and future orbital telescope systems may be retrieved

from the launch configuration, manipulated into the requisite position, and how each hexagonal tile may be attached to

not only the base unit of the spacecraft, but also any neighbouring tiles.

Furthermore, the demonstrator system must then show that a mirror so assembled is functional, manoeuvrable and able to communicate effectively with the robot controller, and ground support.


The strawman scenario on which this OG shall develop is composed by the following main elements:

The optical space telescope, based on the 12m AURA High Definition Space Telescope (HDST) 2

o Spacecraft bus: provide housing and fixation for the Optical Telescope Payload and the Robotic Assembly

System both in stowage and full-deployed state

o Robotic Assembly System (RAS): a robot system that can manipulate Segmented Primary Mirror Tiles

and travel over them to build the primary mirror

o Optical telescope payload:

Segmented Primary Mirror Tiles (SMT): the tiles, shaped in the form of hexagonal prisms that are

1.3m in diameter, once assembled in full-deployed configuration form the primary mirror of the telescope

Secondary mirror, tertiary mirror and focal plane assembly: these are rigidly mounted on spacecraft bus

so that once the primary mirror is deployed the light path is directed through them.

The OG shall focus only on the Robotised Mirror System being made of the elements (marked in bold) that allow

unpacking and assembly of the primary mirror in space.

The work in the OG shall eventually produce a reference implementation (demonstrator) of the Robotised Mirror System,

which is intended to validate the robotics technologies critical for the realisation of the scenario. The demonstrator

breaks down into the following defined units:

demo Spacecraft platform: providing attachment and support for the Robotic Assembly System and for the

Segmented Mirror Tiles, both in stowed and final configuration.

o demo Robotic Assembly System (dRAS), this being functionally representative of the RAS, but designed to

operate in ground conditions. The dRAS shall be composed of the following subsystems:

o A mobile dexterous robot manipulator. This shall provide the mobility and manipulation ability to detach tiles

from their stowage location and attach them in the intended mirror location.

An On-Board Robot Controller (OBC) running ESROCOS to take control of all decision-making and

planning, based upon ERGO and InFuse


the “housekeeping” electronics for monitoring and management of performance

End effectors equipped with SIROM interconnectors

Demo Segmented Mirror Tiles (dSMT), being functionally representative of the SMT, but designed to operate

in ground conditions. The mirror tiles must contain:

2 Association of Universities for Research in Astronomy, From Cosmic Birth to Living Earths: The Future of UVOIR

Space Astronomy, Washington, DC (2015). https://static1.squarespace.com/static/558adc44e4b002a448a04c1a/t/55b8c264e4b041851ef43883/1438171748257/hdst_report_final_072715.pdf

/73


Date 25/10/2017 Issue 1.6

o A control/communication node based on the ERGO via the ESROCOS framework

o An individual mirror

o Internal actuators to enable individual positioning of the mirror

o position sensors enabling accurate localisation of the tile

o SIROM interconnects upon the relevant mirror edges, enabling:

manipulation by the RAS

motion of the RAS

coupling to neighbouring tiles

exchange and transfer of data across the tiles

6.2.2 Reuse of Call 1 Building Blocks


the SRC is mandatory for OG8. The Common Building Blocks must be integrated into the Robot Assembly System and

play a functional role in achieving the stated objectives.

6.2.2.1 ESROCOS

The ESROCOS system shall be used as the core robot control operating system for the RAS. ESROCOS shall be used in

the following capacity:




6.2.2.2 ERGO

The ERGO Controller shall be used and configured so that the RAS may plan and execute its assembly task autonomously.

In particular, it shall be used for:

Executing the mission in its various stages

Managing execution of ground commands

Planning and control of the robot arm

Path and trajectory planning and execution of the robot arm

Planning and control of the robot arm end-effector

Controlling the SIROM connectors to achieve coupling/uncoupling

6.2.2.3 InFuse

The InFuse Common Data Fusion Framework shall be used to create modelled maps of the robot’s situation upon the

base unit, or mirror tiles, with respect to its target, the spacecraft, in order to assist the robot’s decision making and

planning with respect guidance, navigation and control. In particular, the InFuse system shall be used:

To create modelled maps of the Robot Assembly System’s state

To provide the spacecraft with information about the attitude and adjustment of the mirror tiles

To request particular images or data from specific sensors

To fuse information of all sensors

6.2.2.4 I3DS

The I3DS Sensor Suite will be a plug n’ play collection of sensors required for the RAS to achieve its goal of retrieving,

coupling and assembling the mirror. It is incumbent upon the OG8 consortium to specify exactly which sensors would be

required to fulfil the needs of their particular design, but the sensor suite shall:

Provide the ICU to enable centralisation and pre-processing of certain sensor data output

Provide information to the autonomous controller and data fusion framework needed to make decisions with

respect to:

o Manipulation (Approach, grasp, latch, connect)

/73


Date 25/10/2017 Issue 1.6


OG8 is expected to reproduce/procure all the elements of I3DS needed for the work in OG8.

6.2.2.5 SIROM

The SIROM interconnector shall be used as the hardware connection for all coupling points where the mirror tiles

comprising the telescope will be attached. Given that the Robot Assembly System also must grasp, couple, attach and

release the mirror tiles, the SIROM Connector shall also be used as the point of interface upon the robot itself. With this

in mind, the SIROM connector shall:

Be used to attach/detach all mirror tiles with their neighbour(s)

Enable interface and exchange of thermal, electrical, data and mechanical loads and flux between tiles

Be the principal method by which the Robot Assembly System will retrieve, manipulate and couple the mirror

tiles in their allotted position.

OG8 is designated to receive the hardware items produced/procured by SIROM upon the completion of

OG5. OG8 shall also be the Product Maintainer of the SIROM products, as stated in §6.4.1.1.

6.3 Work Logic












The activities related to the coordination within and outside the Consortium are detailed in §6.5.



OG8 shall be responsible for the central maintenance of OG5 SIROM interconnect. This means OG8 shall:

Maintain an online repository where all relevant software & hardware developments must be securely kept

Be the point of contact for disseminating and receiving new code, addendums and features of the SIROM

interconnector

Integrate any changes or new features with the central version



The task is to assess and survey the state-of-the-art in the field of robotic assembly, in robotic systems currently being

used or developed for terrestrial and/or space-based use. The Technology Review shall assess the state-of-the-art as well

as the products being developed by OG1-5.




/73


Date 25/10/2017 Issue 1.6












data requirements

S/W requirements

The System Requirements will be captured in a dedicated deliverable document, which is to be presented for review

at the SRR, as stated in §4.


The System Requirements deliverable as described in 6.4.2 will form the basis for the preliminary design of the

Robotised Mirror System. Task 2 will therefore comprise the following actions:






suit this OG.






The Preliminary Design will be captured in a dedicated deliverable document, which is to be presented for review at

the PDR, as stated in§6.5.5.

6.4.4 Task 3: Detailed Design of Demonstrator and related test Setup

To complete this task the consortium must complete and collate the following individual deliverables:

The detailed design of the demonstrator of the Robotised Mirror System, and the definition of the work required

to realise it

A detailed design of the V&V testing scenario and requirements

The definition of the work required to adapt/develop the products developed in OG1-5

All outputs from this task will be captured in a dedicated deliverable document, stored in a dedicated branch of the GIT

repository, and presented to the PSA at the Critical Design Review, as stated in §6.5.5.

6.4.5 Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment

This task takes as input the results of the CDR to provide the final, integrated demonstrator of Robotised Mirror System

and related test equipment.

This task takes as input the results of the CDR to provide the final, integrated model of the demonstrator as fully

functional representative of space scenario.

At the end of this task it shall be possible to immediately initiate the demonstration tests. Therefore the task shall at least

include the following individual activities:

/73


Date 25/10/2017 Issue 1.6






documentation)


The demonstrator is to be presented for review at the TRR, as stated in §6.5.5.



and analysis of data to validate the implementation of the Robotic Assembly System and Mounted Mobility System, or

assess any non-conformance.


The task shall be concluded with a Final Acceptance (FA) and Demonstration Event, where results of the test campaign

as well as a complete robotised assembly operation (from RvD to detach) are to be presented, as stated in §6.5.5.

6.5 Programmatics

6.5.1 Schedule

The OG will run according to the sequence of tasks stated at §0. The OG is required to report periodically and present the

results during meetings and reviews (milestones) in certain time steps.

Some of the milestone of the OG are however in common for all the OGs in the SRC. The precise date of these common

milestones will be determined by the SRC Board, established following the Collaboration Agreement.

6.5.2 Duration


6.5.3 Management

The Consortium of the OG shall create a management plan listing all activities required under task 0.

The consortium of the OG has to make sure all meetings outlined in 6.5.5 are going to be organised in time.

Other consortium meetings/teleconference can be organised as-needed.

Meetings with other OG Consortia can also be organised as-needed

For any meeting the PSA consortium shall be invited.





6.5.4 Reporting


months a progress report, that records:

the technical description and state of advancement of the work and results in the reference period

updated schedule

action item list

the exploitation plan based on the results gained since -T0-

the dissemination done in the reference period

/73


Date 25/10/2017 Issue 1.6

updated plan for the next 3 months







each submission.

Every presentation given within the Operational Grant has to be submitted in the Microsoft Powerpoint (PPT or PPTX)





KO Kick-Off T0





FA Final Acceptance and

Final Presentation

T0+24 months


6.6 Deliverables

6.6.1 General



6.6.2 Documentation






/73


Date 25/10/2017 Issue 1.6


OG8-D1-System Requirement Document SRD SRR PU







OG8-D8-Videos FA PU





FA

CO-1


FA

PU


FA

CO-1

Table 5 Core deliverables required for OG8



Cluster:

Any hardware procured or produced in the frame of the grant, shall be delivered to the PSA for supporting the

evolution of the technology in the next step in the SRC.

Any software produced in the frame of the grant, shall be delivered to the PSA for supporting the evolution of the

technology in the next step in the SRC.


6.7.1 Definitions and Product Tree

The definitions provided at § 6.2.1 are here briefly repeated. The main product to be developed is a demonstrator of

the Robotised Mirror System, which breaks down into the following defined units:

demo Spacecraft platform:

demo Robotic Assembly System (dRAS),

demo Segmented Mirror Tiles (dSMT)

The demonstrator shall be used to validate the following scenario of assembly.

Whether the mirror will be assembled from its centre point to the outer edge, or from an edge to the others, the assembly

of the mirror will happen in two logical stages: firstly, the deployment and assembly of the inner ring of tiles; and

secondly, the assembly and attachment of the outer rings of tiles.

The difference of the two stages is that the inner ring may be assembled without any need for the RAS to move from the

spacecraft. However, for the outer rings, it is foreseen that the RAS will need to move, or traverse, the mirror itself in

order to reach the tile connectors at the outer edge of the telescope. Therefore an integrated mobility mechanism shall be

created to enable the robot to complete this task.

The Inner Ring

Once in orbit and at the point of deployment, the RAS must first position or deploy itself upon the base unit (Tile 0) of the

spacecraft. The RAS shall deploy itself in such a position so as to be able to retrieve the tiles from the spacecraft bus and

assemble them in the first ring. The RAS shall work to a prescribed schematic of the mirror which is housed by the robot

control system and from which all commands and plans will be derived. The suggested order in which the tiles may be

/73


Date 25/10/2017 Issue 1.6

assembled is shown in Figure 6. The RAS must be able to autonomously grasp, remove, and manipulate the tiles into the

required position.

Once in position, the RAS shall attach Tile 1 to the base unit of the spacecraft using the SIROM connector, as shown in

Figure 6. Tiles 2 and 3 may be attached to the Base Unit and also the preceding tiles, using SIROM connectors, as shown

in Figure 7. The SIROM connector shall be used to achieve a latch, and then a full connection with neighbouring tiles or

the base unit of the spacecraft.

Figure 6: Showing the Robot Assembly System attaching Tile 1 the base unit (Tile 0)

Figure 7: Showing the attachment of tiles 2 and 3 to the base unit

The Outer Ring

Once the first three tiles are in place, the Robot Assembly System must make use of the its integrated mobility (see below)

in order to reach a position from where the attachment and assembly of the final two tiles can be achieved. Tiles 4 and 5

shall be attached from this position. The SIROM interconnector shall be used to realise these connections.

/73


Date 25/10/2017 Issue 1.6

Figure 8: Tiles 4 and 5 being attached to the mirror

Mobility of the RAS

In order to attach and assemble the outer ring of the mirror, the RAS shall traverse across the mirror tiles to reach the

outer ring. It is foreseen that, in order to create a robotic system that can assemble mirrors of any distance, mobility

provisions shall be incorporated into an integral part of the design of the mirror tiles and/or the connectors between the

tiles themselves. The method of traversal shall be decided by the OG8 consortium: it may be a walking robotic arm, a

monorail system, or some other design.

It is anticipated that suitably placed additional SIROM interconnect may facilitate the traverse of the robot.


The demonstrator of the Robotised Mirror System shall:

OG8-R01 Allow validation of the assembly method described in this document with respect to the intended

application

OG8-R02 Allow validation of the assembly interfaces

OG8-R03 Allow validation of the internal positioning system of the mirror tiles


The demonstrator of the Robotised Mirror System must make use of the OG1-5 products in order to implement the

system effectively in line with SRC requirements, as stated in section 6.2.2. The availability of each Common Building

Block will be as follows:

OG8-R04 All bidding consortia for OG7-11 will all be able to access the preliminary designs for the ESROCOS,

ERGO, InFuse, I3DS and SIROM projects.

OG8-R05 Licences for the relevant products will be legally established in time for the Kick Off for OG7-11

OG8-R06 Licences, full system and test designs will be available for project Kick-Off

OG8-R07 Full test results and Final Assessments of Common Building Blocks will be delivered before the

Preliminary Design deliverables for OG7-11 must be submitted to the PSA.

In order to implement the effective testing of the OG8 systems, suitable testing facilities, equipment and locations must

be identified.

/73


Date 25/10/2017 Issue 1.6

7 RESEARCH WORK AND DELIVERABLE DESCRIPTIONS FOR THE ROBOTISED RECONFIGURATION OF SATELLITES (OG9)

The purpose of this section is to define the scope of the work on the robotised reconfiguration of satellites for Operational

Grant 9.

7.1 Scope

Proposals to construct serviceable satellites that could be assembled and re-furbished in space have been put forward by

several space actors in the past. However, these proposals were quickly dismissed on the fear that the provisions needed

on a serviceable satellite made it more complex, heavier and hence more expensive, than a disposable one.

Advances in technology, trends in size and weight of commercial and scientific satellites and platforms as well as the

increased bus standardization (due to the reduction of satellite manufacturers) have changed past considerations. Also,

the demand for cost reduction and business cases in space on the part of government as well as the required reduction of

time for new technologies applied in space play a prominent role.

Modern concepts for standardization and modularization of future space systems are enabling autonomous maintenance

and servicing using robotic systems. These concepts focus on performing on-orbit-servicing operations such as

maintenance repairs or upgrades with the aim to increase lifespan, performance or even change the mission objective of a

space system. Innovative and prospective concepts deal with on-orbit-assembly of such highly modular approaches,

where the maintainable, extendable space system is assembled in space, e.g. on a robotised platform, by dedicated

functional modules. Modular designs have in general positive effects on the overall mission effectiveness by allowing re-

use of modules across different space products and rapid development of systems. The system intelligence is distributed

and growing by each functional module added.

Those systems evolve from a “stupid satellite” to a smart satellite, a robot: a necessary step for a sustainable, highly

automated space infrastructure.

Figure 9 Future Perspective – orbital platform with platform-mounted robot system performing servicing and assembly tasks (left) 3, Satellite-mounted robot system able to use modular structure for

reposition (right)

A further step in modularisation, which assumes standard sizes of modules with standard interconnects among them

(Design to manufacture/production), can bring additional benefits by introducing flexibility in the assembly of the

modules not only in space reconfiguration but also on ground production. Different modules can be designed to

implement different spacecraft/payload functions and may have different composition abilities so that from a limited set

of functional modules, a designer may assemble spacecraft/payload with different properties. Standardisation in shape

and in connection properties is baseline for a reduction of AIT effort.

3 M. Goeller et al., Modular Robots for On-Orbit Satellite Servicing, Proceedings of the IEEE International Conference on Robotics and Biomimetics (RoBio12), 2012

/73


Date 25/10/2017 Issue 1.6

Such design effort would need to be supported by dedicated software for automation and robotic compatible satellite

design, reconfiguration planning and simulation so that design of new spacecraft/payload would be reduced in time and

costs.

The potential for a highly modularised satellite design and production system with the increased flexibility of satellites

built/reconfigured accordingly, will improve the competitiveness of European industry. Building set approaches will

enable simplified processes for the quick introduction of new terrestrial technologies into space. The positive economic

effects resulting from increased sustainability of space missions are also accompanied by ecological benefits such as the

reduction of space debris.

The primary purpose of the OG is to demonstrate the scenario in which a spacecraft can modify the functionality of

platform/payload by adding/replacing functional modules available on-board or provided by another servicing satellite,

by means of a spacecraft mounted robot manipulation system.

In this context, the robotic manipulation is of fundamental importance. The robotic manipulator thereby shall be able to

move and assemble the functional modules in a 3-dimensional way. To cope with this task, a key ability of the robot

system shall be self-relocation, which means that the system is movable so as to be secured to any one of a number of

fixtures which are spaced from one another on a support structure. The modified spacecraft shall be reconfigured in order

to perform new mission tasks.


OG9 represents a scenario to design and demonstrate an innovative, fundamental but also ambitious approach for a

highly automated sustainable space infrastructure. A platform-mounted robot system which is able to reconfigure an

operated satellite -by extending and upgrading its capabilities with functional modules- which are connected via standard

interconnectors. In this scenario, modules are delivered by a servicer satellite. Afterwards, the upgraded satellite system

performs new, additional mission tasks. Up to certain extent, those systems can adapt to new tasks very easily, the path

towards smart satellites is opened.

To attain the primary purpose, the OG shall design and develop a demonstrator of the scenario featuring:

a satellite-mounted robot system having the necessary mobility and manipulation abilities

stock of functional modules having the necessary interconnections and composability

a satellite mock-up as demonstrator platform having the necessary connectors for functional modules

and prepared for reconfiguration tasks (satellite software framework, etc.)

design and simulation software to plan and simulate the reconfiguration phase of the upgraded satellite

with the servicing tasks of the robot system

The demonstrator shall be integrated in an orbital simulation facility to validate in tests the scenario.

Supporting the development and test activity, the handling of complex building block architectures in a

reference mission scenario shall be demonstrated with the help of a proper design and simulation tool

with regard to the requirements and constraints of the robotics, structure and the entire system. The software shall

support engineers developing new components and satellites and shall give system integrators the chance to test the

entire satellite including all relevant aspects of on-orbit assembly and servicing operation.


The system to be designed, developed and demonstrated breaks down into the following defined units:

a. Satellite-mounted robot system:

The satellite-mounted robot system is required to modify the spacecraft by repositioning and adding functional

modules. It is composed of the following major assemblies:

a general purpose or special adopted/developed robotic arm including

o electromechanical joints with control electronics

o suitable end-effectors on both sides for self-repositioning (“walk on the platform”),

manipulating function modules and exchanging data with modules (“communicate with the

module”)

o necessary sensors to fulfil its purpose

o necessary software interfaces to fulfil its purpose

/73


Date 25/10/2017 Issue 1.6

o the housekeeping electronics for temperature monitoring and control

a multi-purpose On-Board Computer (OBC) and required robotic control software compatible to

platform S/W framework for modular spacecraft

b. Stock of functional modules:

Functional modules are containers with integrated subsystem components (ASM=Active System Module) or

payload components (APM=Active Payload Module), which can be used to fulfil a certain task (e.g. special

sensor equipment for an experiment or enhanced computation power for robotic tasks).

The stock of functional modules consists of the following assemblies:

the number of functional modules in total (APM/ASM) shall not be less than 6

o at least 3 modules shall be configured as ASM

o at least 2 modules shall be configured as APM

all modules shall have a sufficient number of interconnectors in order to manipulate them with the

robot system and to couple them with each other and to the platform

the assembled modules shall be able to switch to redundant data and power paths

the standard interconnector of a module shall allow to transfer mechanical loads, electrical signals and

data as well as thermal flux (optional configuration of the interface possible)

a servicing robot shall be able to “communicate” with module attached through its manipulator due to

the data transfer capability of the interface

the structure of the modules shall be able to carry the loads introduced by the “walking” robot-system

the structure shall be prepared in order to accommodate different kinds of (subsystem) components to

generate easily different functional upgrades for spacecraft

a multi-purpose On-Board Computer (OBC)

compatible to platform S/W framework for modular spacecraft

c. Satellite mock-up as demonstrator platform

The satellite mock-up is required to test and demonstrate the implementations done in this operational grant.

The mock-up platform consists of the following assemblies/characteristics:

A top level software framework suitable for a modular system approach that supports:

o identification of additional functional modules

o identification of fault system elements (e.g. a defect interface of a module)

o plug&play principal for functional modules (functional modules can be connected to a running

system; the system reconfigures and uses the functionality of new modules)

o data and power path allocation within the whole system

consist of at least 6 interconnectors

o for the installation of additional functional modules

o for the connection (anchor point) of the robot system

the standard interconnector of shall allow to transfer mechanical loads, electrical signals and data as

well as thermal flux (optional configuration of the interface possible)

host the robot system, which is able to reposition itself on the interconnections

able to be reconfigured after installing multiple functional modules

d. Design and simulation software

The software shall allow users to simulation and test high-modular building block space system architectures

with regard to the requirements and constraints of robotics, structure and the entire system. It shall be used to

plan and to test the servicing task of the robot system. The software shall consist of the following

assemblies/characteristics, at least:

the user shall be able to test and simulate the demonstration scenario of the OG, at least regarding

o mechanical/dynamical loads

o thermal loads/thermal control

o distribution of resources (e.g. power, data-connections, computation power, …)

the user shall be able to

o add functional modules to the spacecraft or combine different modules

o to perform the reconfiguration process of the spacecraft

o simulate the servicing task considering dedicated robotic specifications

/73


Date 25/10/2017 Issue 1.6

o extract a plan for the servicing task of the robot

o transfer the servicing task to the robot system in the orbital test facility

standard interfaces to other commonly used software products in space and terrestrial applications


The functional requirements and capabilities of the system are listed in 7.7

The proposed demonstration shall demonstrate the robotised reconfiguration of a satellite platform with hosted payload

to a hybrid satellite platform. In this context, a hybrid satellite platform is composed of a standard satellite platform

and multiple functional and exchangeable modules, in which parts of subsystems are housed.

The demonstration includes the following phases:

1st Operation phase: satellite platform is equipped with different sensors and performs observation mission

objectives. One sensor is installed in platform, another experimental sensor (IOV) in an APM. The system

detects a failure in an APM connector, which interrupts transfer of sensor data from APM to the platform. The

system shall be repaired and reused/upgraded with new technology in order to perform new mission tasks.

Servicing preparation phase: Servicing/upgrade task shall be simulated in software. After successful planning

and testing, the servicing plan shall be transferred to the satellite platform.

Servicing/Reconfiguration phase: the platform shall use its mounted robot system to reconfigure in 3-

dimensions, whereby the additional functional modules are taken from “transport” platform (it is assumed, that

the additional modules are delivered by a separate servicer platform, which is docked/latched to our maintained

platform). The APM with the defect interconnector has to be repositioned, so that a working interconnector is

used. Also the capability of repositioning of the manipulator shall be demonstrated. The serviced platform has to

detect all new functionalities, to reconfigure the software and adapt to new mission tasks.

2nd Operation phase: the upgraded, hybrid platform (not only APMs but also ASMs) has to demonstrate new

functionalities by performing new mission tasks. Furthermore, a defect interconnection has to be simulated

which shall also demonstrate advantages of a modular, decentralised “smart satellite” approach regarding

redundant computational power, data paths, etc.

Figure 10 Principal demonstration of OG9 objectives “robotised reconfiguration: pathway from satellite

to smart satellites” (reference implementation)


Consortia proposing for OG9 shall use primarily the products of OG1-5 as key components in their solution. In order to

ensure the perfect compatibility and functionality of each of Call-1 technologies, modifications on them are allowed. For

OG9 the resulting technology of OG5 “Modular interfaces for robotic handling of payloads” is of highest importance. The

/73


Date 25/10/2017 Issue 1.6

modular interface shall be the basis for the ASMs/APMs to be manipulated by the satellite-mounted robot system. For the

reconfiguration and allocation of resources from ASMs/APMs to other ASMs/APMs or the platform, the results of OG1

ESROCOS “Robot Control Operating System” and OG2 ERGO “Autonomy framework: time/space/resources planning

and scheduling” are fundamental.

This Operational Grant shall implement the “building blocks” developed during previous SRC’s phase, namely OG1-5,

addressing in detail.

7.2.3.1 ESROCOS

The system shall be equipped with the provided ESROCOS system in order to control the system mounted robot

It shall be investigated, how the autonomy framework (OG2) and RCOS (OG1) can be extended to a top-level

software framework, which operates a modular, decentralised system

7.2.3.2 ERGO

The software framework of a modular, decentralised (robotic/smart satellite) system shall be able to detect and

use additional functional modules (plug&play principle). Together with ESROCOS it shall be able to control the

robot on the platform, which has up to certain extent autonomous features, adapted to the specific operative

tasks

It shall be investigated, how the autonomy framework (OG2) and RCOS (OG1) can be extended to a top-level

software framework, which operates a modular, decentralised system

7.2.3.3 InFuse

The platform shall implement sensor data fusion techniques from OG3 applied to self-provided measurements

(i.e. provided by its equipped sensors)

7.2.3.4 I3DS

The satellite shall be equipped with its own integrated sensor suite derived from OG4 I3DS in order to connect

different types of sensors. The sensor suite shall be able to integrate multiple sensors at system level

In OG9 at least two types of sensors are going to be needed:

Sensors to be integrated in an APM

Sensors to be mounted in the platform

OG9 is expected to reproduce/procure the elements of I3DS sensor suite needed for the work in OG9.

In addition, it is not excluded to revisit the architecture of the I3DS ICU if an alternate design appears relevant.

7.2.3.5 SIROM

The required H/W units in OG9 (platform, ASMs/APMs, robot) shall be equipped with standard interfaces from

OG5.

OG9 is expected to reproduce/procure all SIROM interconnects needed for the work in OG9.

7.3 Work Logic


/73


Date 25/10/2017 Issue 1.6









with other Consortia recipient of Operational Grants in the SRC, if necessary


The activities related to the coordination within and outside the Consortium are detailed in section 7.5.



OG9 shall be responsible for the central maintenance of OG1 ESROCOS robot control operating system.

This means OG9 shall:

Maintain an online repository where all relevant software developments must be securely kept

Be the point of contact for disseminating and receiving new code, addendums and features of the ESROCOS

system




The Technology Review aims to obtain a survey of the existing technologies relevant for the robotised reconfiguration of

satellites, in particular for satellite-mounted robot system, functional modules, sensors and required software for the

system and ground support.

Moreover, the Technology Review shall assess the state-of-the-art as well as the products being developed by OG1-5









System Requirements shall be identified, in terms of:





data requirements

S/W requirements



The subtasks mentioned above, run in parallel with check-points in order to compare the requirements defined at system

level with the current technological readiness. At the end of both tasks, it shall be possible to state the following:

what are the current technologies & software solutions relevant for a satellite-mounted robot system, hybrid

satellite platform with connected ASMs/APMs and the ground support tools (design and simulation S/W)?

/73


Date 25/10/2017 Issue 1.6

what is the performances/functionalities gap between the existing technologies and the system need?

what effort is required to realize the necessary design and S/W adaptation and development?

what is the TRL gap between the existing technologies and the required TRL?


The System Requirements as described in §7.4.2 will form the basis for the preliminary design of the hybrid

satellite platform with connected ASMs/APMs, satellite-mounted robot system and the ground support tools

(design and simulation S/W). to validate the application scenario, establish test procedures




suit this OG.






The Preliminary Design will be captured in a dedicated deliverable document, which is to be presented for review at

the PDR, as stated in §5.4.3.

The design shall be recorded in the GIT repository.

7.4.4 Task 3: Detailed design of Demonstrator and related test setup

The task shall include all activities needed to identify, define and design the elements allowing the demonstration of the

sought hybrid satellite platform with connected ASMs/APMs, satellite-mounted robot system and the ground support

tools (design and simulation S/W).

At the end of this task it shall be possible to immediately initiate the manufacturing/coding/procurement, integration and

testing of the elements of the scenario demonstrator. Therefore the task shall at least include the following individual

activities:

Definition and Design of the satellite-mounted robot system

Definition and Design of the satellite platform

Definition and Design of the set of ASMs/APMs

Definition and Design of the design and simulation software

Definition and Design of unit testing and integration testing in the developed simulation software and in the

orbital the facility

Definition of test goals and their schedule


GIT repository.

The Detailed Design is to be presented for review at the CDR, as stated in §4.

7.4.5 Task 4: Manufacturing, Assembly and Integration of demonstration and test equipment


demonstration of the sought hybrid satellite platform with connected ASMs/APMs and the satellite-mounted robot

system (and the ground support tools). This task takes as input the results of the CDR to provide the final, integrated

model of the demonstrator as fully functional representative of space scenario.






/73


Date 25/10/2017 Issue 1.6





documentation)



and analysis of data to validate the implementation of the hybrid satellite platform with connected ASMs/APMs and the

satellite-mounted robot system (and the ground support tools)or assess any non-conformance.

All tests have to be reported, the results must be written into a summary report.

At least, the following tests shall be performed:

Perform functional test of the design and simulation software

Perform functional test of the satellite-mounted robot system

Perform functional test of each module

Perform robotic servicing test (coupling/de-coupling of modules, H/W reconfiguration)

Perform functional test of the hybrid satellite platform with connected ASMs/APMs

Perform a reconfiguration test (different task allocation depending on mission task, e.g. switch from camera

equipment to communication equipment)

Perform redundancy test (simulation of a module defect/interface defect)


The task shall be concluded with a Final Acceptance (FA) and Demonstration Event, where results of the test campaign

are to be presented, as stated in §4.

7.5 Programmatics

7.5.1 Schedule

The OG will run according to the sequence of tasks stated at section 4. The OG is required to report periodically and

present the results during meetings and reviews (milestones) in certain time steps.

Some of the milestone of the OG might be in common for all the OGs in the SRC. The precise date of these milestones will

be determined by the SRC Board, established following the Collaboration Agreement.

7.5.2 Duration


7.5.3 Management

The consortium of the OG shall create a management plan listing all activities required under section 7.2 .

The consortium of the OG has to perform all meetings defined in section 4. Meetings with other OG Consortia can be

organised as-needed.

For any meeting, the PSA consortium shall be invited. All meetings shall be announced with an Agenda of the items to be

discussed.




/73


Date 25/10/2017 Issue 1.6

7.5.4 Reporting

The OG consortium shall produce periodic reports on the status of work. For this OG it is required to submit every 3

months

a short progress report, that records


updated schedule

action item list



updated plan for the next 3 months (at least)

The OG consortium shall produce a final report being a complete description of the work done within the 24 months of


The OG consortium shall finally produce:



Each report has to be submitted in Microsoft Word format. A copy in Adobe PDF format has to be added to each

submission.

Every presentation given within the Operational Grant has to be submitted in the Microsoft Powerpoint format. A copy in

Adobe PDF format has to be added to each submission.


The Milestones of OG 9 are defined in Table 6. The milestones are associated to reviews with the participation of the PSA.

# Meeting Schedule

KO Kick-Off T0

SRR System Requirements review (M1) Tentatively T0+3 months

PDR Preliminary design review (M2) Tentatively T0+9 months

CDR Critical Design Review (M3) T0+15 months

TRR Test Readiness Review (M4) T0+22 months


Final Presentation

T0+24 months


The consortium is expected to establish additional Progress Meetings, with the frequency of 1 every 2


7.6 Deliverables

7.6.1 General



7.6.2 Documentation






/73


Date 25/10/2017 Issue 1.6




Cluster:





7.7 ANNEX - User Requirements

On-Orbit servicing (OOS) and On-Orbit assembly (OOA) are required capabilities for a sustainable and automated space infrastructure. Modularity of functional spacecraft elements and standardisation of interfaces and structural parts are key elements for maintainable, extendable and adaptable spacecraft. The efficiency of robotics in terrestrial applications can be brought into in space by introducing a building set for spacecraft, in which standardised modules and interfaces are used to assemble satellites or platforms. Those functional modules should have some basic characteristics like scalability, redundancy, low complexity, low mass, standardised interconnectors and shape, reusability as well as compatibility to robotic servicing. This will allow a low complexity robotic coupling/servicing procedure. Thus, a basic set of requirements for the application defined in this Operational Grant can be seen as necessary capabilities for the next generation of smart satellites in a sustainable, highly automated space infrastructure.


The system to be designed, developed and demonstrated shall at least support the following set of capabilities/

operations:

OG9-R01 The robot shall be able to add and replace whole functional modules (ASM/APM) by using the

interconnectors of these modules.

OG9-R02 The robot shall be able to repair or update an integrated subsystem or payload component of an

existing APM by repositioning it.

OG9-R03 The robot shall be able to reposition itself by using the interconnectors/structure of the functional

modules or the platform


OG9-D1-System Requirements Document

(SRD)

SRR PU




OG9-D5-Detailed Design Document (DDD) CDR PU



OG9-D8-Videos FA PU



OG9-D11-Final report and Final Presentation FA PU

OG8-D12-Technology development plan SRR, updated at CDR, finalised at

FA

CO-1

OG9-D13-Dissemination plan SRR, updated at CDR, finalised at

FA

PU


FA

CO-1

/73


Date 25/10/2017 Issue 1.6

OG9-R04 High-level control of the robot is performed by the platform system: it executes and monitors the

reconfiguration plan, which was generated in the software with symbolic actions. The execution of these

actions and basic motor control is performed by the robot itself.

OG9-R05 The platform shall be able to reconfigure and use new functionalities brought by additional functional

modules

OG9-R05.1 The platform functionality of the satellite shall be upgraded by functional modules

OG9-R06 The platform shall be able to monitor the status of essential parameters of each connected functional

module

OG9-R07 The system shall be able to reallocate resources (e.g. power, data, computational power, etc.) and assign

different paths through the hybrid system automatically in case of a defect (e.g. interconnector of an

APM)

OG9-R08 The system shall be able to handle the described scenario even during a connection failure or a power

interruption of defect modules/interconnectors.

OG9-R09 The design of the satellite-mounted robot and the functional modules shall be such that the later

product is able to withstand the harsh conditions in space.

7.7.2 Implementation requirements

In order to successfully implement all the necessary functionalities for the system (demonstrator) of the scenario defined

at hand, the following aspects have to be taken into account:

OG9-R10 The technologies/products of Call1 have to be used according to the definition in section 3.

OG9-R11 The ASMs/APMs shall be able to integrate subsystem parts/components

OG9-R12 The design and simulation software shall be able to simulate the system with all related robotic

elements and tasks (e.g. reconfiguration) as well as create a robotic compatible servicing plan for the

satellite platform

OG9-R13 In order to implement the effective testing of the OG9 demonstration scenario, suitable testing

facilities, equipment and locations must be identified

7.7.3 Verification requirements

OG9-R14 The verification shall be performed in a step-wise manner: Step 1: Calibrate/verify simulation tool developed/provided in this OG for the verification process

Step 2: Simulate/verify the whole system and demonstration scenario respectively, simulate the reconfiguration process and generate a robot servicing plan for the use in the orbital test facility.

Step 3: Test and verify the demonstration scenario in a suitable orbital test facility.

/73


Date 25/10/2017 Issue 1.6

8 RESEARCH WORK AND DELIVERABLE DESCRIPTIONS FOR THE AUTONOMOUS DECISION MAKING (OG10)

8.1 Objectives

The goal of the planetary track of the SRC is to accomplish a major breakthrough in space science, human exploration and

space resource utilization through the deployment of robotic systems. Planetary track comprises activities leading to

future robotic technologies for planetary exploration / exploitation (>2030).

The first target for the planetary track is to increase science return by developing more autonomous robotic probes.

The challenge of this activity is to integrate a demonstrator of a planetary rover system with long traverse capabilities (a

few kilometres a sol), which will manage independently the decision required to reduce risks and seize scientific

opportunities. Such a rover system will be required to travel autonomously from a starting point (e.g. a lander) towards

an end point (say, a cache of samples), perform independent opportunistic science in the way and return to the lander

with the acquired soil sample.

For planetary exploration vehicles, there is a trade-off to be found between detailed and accurate observation of the areas

traversed to ensure that potentially interesting targets from a scientific point of view are not missed (which means slow

traverses and downlink of a huge amount of data), and maintaining sufficient progress to visit many science targets

(which means higher speed but less accurate observation to reduce the amount of data to be downlinked).

The main focus of this activity will be the maturation of autonomy approaches capable of interpreting abstract situations

and manage efficiently various objectives in presence of tight temporal and energy constraints. In brief the sought

capabilities of the rover, which will be realized in an Autonomy Decision-making and Action-taking Module (ADAM) are:

Autonomous long range navigation

Long term mapping & path planning / Adaptive execution of activities: By autonomous long-term navigation is

assumed the capability of a system to perform autonomously its mapping, path planning and motion control

over distances in the range of 1km per sol.

Opportunistic science : By opportunistic science is meant the ability of the system to perform all or part of the

following:

o to detect in the surroundings/landscape an interesting target from a scientific point of view and store the

corresponding image,

o to assess the relevance/scientific value of this target (criteria, time, distance, …) for complementary data

collection,

o to approach this target (using visual tracking) if it is regarded as valuable enough and if it is too distant for

performing the complementary data collection,

o to execute the complementary data collection

Decision making in presence of conflicting objectives: this refers to the ability to maximize scientific yield in presence

of tight temporal (sol duration, limited life duration), energy (power generation and storage) and resources (mass

memory, uplink budget) constraints. Beyond the decision process, the following planning activities will be involved

to implement the opportunistic science:

o to change the rover route towards a detected scientific target

o to plan activities concerning the in-situ science

o to come back to its initial route after having performed the needed science

This opportunistic science objective is regarded as particularly challenging since it addresses multiple capabilities with

low maturity. After the technology review, some descoping can be therefore envisioned through the emulation of some of

these capabilities (see further down).

The increase of the autonomy level leads also to new challenges from the verification standpoint since there is no

possibility to simulate the plan execution as it is foreseen for the Exomars rover. A particular effort will have to concern

the development of a consistent validation approach and toolset devoted to the decision-making framework.

To develop these capabilities, the activity performed within this OG will have to rely on the outputs of the 1st call of the

SRC, that is to say on the building blocks delivered by the OGs of the 1st call.

/73


Date 25/10/2017 Issue 1.6

Figure 11 Example of scenario combining manually and autonomously targeted scientific site of interest


The OG shall produce a demonstrator of planetary rover system with long traverse capabilities (a few kilometres a sol),

which will manage independently the decision required to reduce risks and seize scientific opportunities. This

demonstrator shall be made of

A rover system, made of:

o A rover vehicle (made available by the OG consortium, not developed and delivered)

o A suite of sensors for navigation & science and its data processing unit (to be procured by the OG

consortium in case OG4 products are either unavailable or incomplete).

o The autonomy decision making module (ADAM), developed on OG1, OG2 and OG3 products)

Testing facilities:

o an analogue test environment (made available by the OG consortium). By analogue environment is

meant a testing environment, which would be representative of a Martian-like environment for

topological, lightning conditions constraints.

o equipment suite providing ground truth (terrain model and robot reference localization)

a ground control simulator consisting of

o ground station, developed within the OG, which would be responsible for the preparation of the tests.

This ground station would require a minimal set of functionalities, among which shall be included the

capability to select a target, sending instructions to the vehicle, compressing and post-processing the

data sent back by the vehicle

o a software validation toolset implementing an accurate rover system simulator

/73


Date 25/10/2017 Issue 1.6

Figure 12 Preliminary architecture of the ADAM

8.2.1 Assumptions to be considered for the study

Mission duration: with the challenge being focused on the system autonomous capabilities, it is preferable to

multiply the situations in which the autonomy will be exercised (1 sol duration) rather than considering longer

scenarios that imply multiple interactions between the ground and the remote system.

Communications constraints: communication rate and latency representative of a typical Mars mission must be

considered for both scenario and system design. The communication latency will not be simulated per se in the

communication process but will be taken into account in the mission scenario schedule. Conversely, the

communication rate will be simulated using a direct (rate saturation mechanism) or indirect approach

(saturation of the transmitted data volume). Note that such a constraint will not concern the data logging.

Mission plan examples:

o Traverse at least a given distance in a specific direction under time and energy constraints

o Pass through a minimum set of way points with a given accuracy under time and energy constraints

o Reach a given goal with a certain accuracy under time and energy constraints (and possibly passing

through specific waypoints)

Opportunistic science: The main purpose of OG10 is to demonstrate a planetary rover system capable to achieve

long traverse capabilities and manage possibly conflicting objectives along the way. The detection of interesting /

unknown patterns within images has still a low maturity level and the effort devoted to the development of such

a functionality should therefore be sized in a sound way. Even though the autonomous detection functionality is

a necessary component of the system, some de-scoping can be envisioned through a reduction of its level of

representativeness. This functionality should be able to raise flags when some “interesting” situation has been

detected, and several options could be envisioned for its implementation:

o High profile: objects with real scientific value and whose signature can be identified with the current

state of the art are placed on the testing site

o Medium profile: conspicuous objects present on the testing site and identifiable with the current state

of the art are considered as scientific “mock-ups”

o Low profile: scientific object “mock-ups” whose signatures can be identified with the current state of

the art are placed on the testing site


Consortia proposing for OG10 shall use primarily the products of OG1-5 as key components in their solution. In order to

ensure the perfect compatibility and functionality of each of Call-1 technologies, modifications on them are allowed. For

OG10 the resulting technology of OG2 “Autonomy framework” and OG3 “Sensor Fusion techniques” is of highest

/73


Date 25/10/2017 Issue 1.6

importance. The results of OG1 ESROCOS “Robot Control Operating System” and OG4 I3DS “Inspection suite” are

fundamental. Conversely, the use of OG5 SIROM is not foreseen since the scenario does not involve any plugging / un-

plugging task.

This Operational Grant shall implement the “building blocks” developed during previous SRC’s phase, namely OG1-5,

addressing in detail.

8.2.2.1 ESROCOS

The ESROCOS system shall be used as the core operating system for the autonomous long range navigation and

opportunistic science. ESROCOS shall be used in the following capacity:




8.2.2.2 ERGO

The ERGO Controller (OG2) shall be used and configured so that the rover is capable to perform autonomous long range

navigation and opportunistic science. The ERGO shall be used for:

planning /scheduling the rover activities under time and resource constraints

monitoring the rover activities under time and resource constraints

rover path planning (spatial reasoning) and control

8.2.2.3 InFuse

The InFuse Common Data Fusion Framework shall be used to create maps of the robot’s environment, and estimate the

robot positioning, in order to assist the robot decision making and planning in the tasks of navigation and opportunistic

science. The InFuse system shall be used to:

create environmental maps,

provide the rover controller with information about its absolute and relative positioning

provide images or advanced data from specific sensors

8.2.2.4 I3DS

The I3DS Sensor Suite (i.e. set of sensors and Instrument Control Unit) shall be adopted as the basic model for the sensor

suite implementation on-board the rover. In detail, the I3DS control unit (ICU) shall be adopted as reference kernel for

the management and control of each set of sensors, in order to:

Provide centralization and pre-processing of certain sensor data output

Provide the rover controller, its data fusion framework and the autonomous decision module with all information

needed to perform navigation and opportunistic science

The choice of set of sensors (i.e. sensor model and performance) shall be performed in order to fulfil the scenario

requirements and may be performed by using I3DS one as guideline.



8.2.2.5 SIROM

The use of OG5 SIROM is not currently foreseen.

8.3 Work Logic

The Work Logic scheme is common to all the OGs and it is reported in chapter 4. The shown block diagram highlights the

integrated flow from technology review and system requirements definition up to the final demonstration and acceptance.

/73


Date 25/10/2017 Issue 1.6











The activities related to the coordination within and outside the Consortium are detailed in § 5.5



OG10 shall be responsible for the central maintenance of OG2 ERGO autonomy framework. This means

OG10 shall:


Be the point of contact for disseminating and receiving new code, addendums and features of the ERGO

framework




The initial part of the task is to assess the state-of-the-art in three major fields:

autonomous rover navigation,

image analysis / interpretation compatible with autonomous science,

decision making in presence of conflicting objectives

taking into account their applicability to space robotic systems currently under design (ExoMars) or already existing

(MER, Curiosity). This assessment shall consider relevant projects or programs (referred both to space and terrestrial

applications) that involve mobile robots acting autonomously or semi-autonomously. As regards opportunistic science,

the ESA MASTER project constitutes a necessary reference.

Next, the Technology Review shall assess the state-of-the-art as well as the products being developed by OG1-4.








The main goal of the Technology Review is to obtain a survey of the existing technologies / facilities relevant for the

implementation, management and testing of autonomous navigation/opportunistic science.

classes of methods / algorithms with current maturity level

functional performances and implementation constraints

rover platforms to be used

testing site characteristics

ground truth metrology system

characteristics of scientific targets (or mock-ups) to be used


/73


Date 25/10/2017 Issue 1.6





data requirements

S/W requirements




The System Requirements as described in §8.4.2 will form the basis for the preliminary design of the autonomy module

and its ground station. Task 2 will therefore comprise the following actions:






suit this OG.









This task is the grouping of the following individual activities:

Detail definition of the operations of autonomous rover navigation with decision making

Detail definition of the demonstration tests, at least, the following tests shall be performed:

o tests of a 1 km traverse in a single sol on 3 types of terrains (focus on long range navigation)

o tests of traverses with a minimum distance requirement and multiple targets of different value on the

way (focus on the decision-making capability in presence of conflicting objectives)

o tests of traverses without minimum distance requirement for the sol and presence of multiple targets

on the way (focus on the target detection and plan reconfiguration)

Definition and Design of the different autonomous functionalities (perception/path planning for rover long

range navigation, scene analysis/interpretation, decision-making for planning),

Definition and Design of the Ground Segment functionalities (ground station and validation toolset)

Definition of the work required to adapt/develop the products developed in OG1-5

Definition and Design of the reference implementation

Definition and Design of independent unit testing and integration testing on the test platform

Definition of test goals and their schedule


GIT repository.



demonstration of the sought planetary autonomous operations. This task takes as input the results of the CDR to provide

the final, integrated model of the demonstrator as fully functional representative of space scenario.

/73


Date 25/10/2017 Issue 1.6










documentation)

The demonstrator is to be presented for review at the TRR, as stated in §4. shall be uploaded in the GIT repository.

8.4.6 Task 5: Execution of test, demonstration and correlation of test results.


and analysis of data to validate the implementation of orbital support services or assess any non conformance.


The task shall be concluded with a Final Acceptance (FA) and Demonstration Event, where results of the test campaign as

well as a complete orbital support servicing operation (from RvD to detach) are to be presented, as stated in §4.

8.5 Programmatics

8.5.1 Schedule

The OG will run according to the sequence of tasks stated at §4 The OG is required to report periodically and present the

results during meetings and reviews (milestones) in certain time steps.

Some of the milestone of the OG are however in common for all the OGs in the SRC. The precise date of these common


8.5.2 Duration

The total duration of OG is 24 months from the kick-off.

8.5.3 Management


The consortium of the OG has to make sure all meetings outlined in table (marked with ‘OGx-con’) are going to be

organised in time.


Meetings with other OG Consortia can also be organised as-needed






8.5.4 Reporting


months a progress report, that records


updated schedule

/73


Date 25/10/2017 Issue 1.6

action item list





the Operational Grant. The OG Consortium shall finally produce:




each submission.

Every presentation given within the Operational Grant has to be submitted in the Microsoft PowerPoint (PPT or PPTX)



The Milestones of OG 10 are defined in Table 8. The milestones are associated to reviews with the participation of the

PSA.

# Meeting Schedule

KO Kick-Off T0

SRR System Requirements review (M1) Tentatively T0+3 months

PDR Preliminary design review (M2) Tentatively T0+9 months

CDR Critical Design Review (M3) T0+15 months

TRR Test Readiness Review (M4) T0+22 months


Final Presentation

T0+24 months


The consortium is expected to establish additional Progress Meetings, with the frequency of 1 every 2


8.6 Deliverables

8.6.1 General



8.6.2 Documentation






/73


Date 25/10/2017 Issue 1.6


OG10-D1-System Requirement Document

SRD

SRR PU

OG10-D2-Preliminary Design Document

(PDD)

PDR PU






OG10-D8-Videos FA PU





FA

CO-1


FA

PU


FA

CO-1


Data sets (OG10-D9) will include all information necessary to fully understand the test results and enable some

independent functional and performance analysis (including test replay)

Test plans and configuration data

Data collected during the tests (commands, rover sensor measurements, ground truth data).

A detailed documentation describing the data structuration shall be provided.



Cluster:





8.7 ANNEX 4 – USER Requirements

8.7.1 Definitions and Deliverable Tree

The system shall include the following components:

a. rover system:

i. rover vehicle

ii. Sensor suite

iii. ADAM

b. Ground segment “mock-up”

i. Ground station

ii. Validation toolset (simulator of the robot and its environment, framework enabling to run ADAM

software for functional / performance validation and plan verification)

/73


Date 25/10/2017 Issue 1.6

iii. associated data base (containing all the system parameters and the data collected during the

different tests)

c. Testing facilities composed of:

i. Analogue test sites providing increasing level of fidelity to a Martian environment

ii. equipment suite enabling to provide ground truth (terrain model and robot reference localization)

Figure 13 Overview of the deliverable system. The validation toolset that is a component of the simulated ground system is presented here as an independent element but can be merged with the ground station

if considered appropriate

8.7.2 Functional requirements:

OG10-R1 The robotic vehicle shall possess the following capabilities:

OG10-R1.1 Capability to traverse up to 1 km/sol in categories of terrains that will be defined during Task 2 – the

total duration considered will be actually 6 hours to account for other mission needs (coms, science)

OG10-R1.2 Capability to reach a destination designated by the ground with a given accuracy - this accuracy can be

expressed as a position tolerance e that is proportional to the traverse length d (e = k*d with a target figure k

less than 0.015)

OG10-R1.3 Capability to detect objects of scientific interest within a given distance around the robot - the target

value will be identified during the technology review (Task 1) and approved by PSA at SRR

OG10-R1.4 Capability to assess the relevance/scientific value of this site given a predefined list of criteria

(as mentioned before, such a capability has to be integrated in ADAM even though it will not fully

representative from a scientific point of view)

OG10-R1.5 Capability to decide whether some science activity can be achieved considering the potential value/cost

of the activity, the resources currently available and the “mission” constraints of the day

OG10-R1.6 Capability to perform “mission” re-planning in order to include the activities of opportunistic science

(involving possibly rover and instruments tasks)

OG10-R1.7 Capability to move toward the detected object to perform close observation (using some object tight or

loose tracking techniques) – the values for the close observation distance and the position accuracy will be

identified during the technology and approved by PSA at SRR

OG10-R1.8 Capability to execute the activities of scientific data collection

OG10-R1.9 Capability to detect anomalies and assess their criticality (ex: task not achievable within the allocated

resource, risk of task failure, risk for a robot component, risk for the robot)

OG10-R1.10 Capability to take the appropriate action in case of anomaly (ex: stop the task and continue the traverse,

stop and wait for the ground to take action)

OG10-R2 The ground station “mock-up” shall integrate the following functionalities:

OG10-R2.1 Generation of the mission plan

OG10-R2.2 Verification of the mission plan using the validation toolset

/73


Date 25/10/2017 Issue 1.6

OG10-R2.3 Plan activation and supervision of its execution

OG10-R2.4 Collection and storage of all data (robot and ancillary data) necessary to:

enable the assessment of the robot behaviour and performances during the plan execution

enable the replay of the plan execution (to perform detailed analysis of some particular

functionality and/or perform parameter tuning)

OG10-R2.5 Management of the system and test data base

OG10-R2.6 Exploitation of the test data for analysis of the system behaviour / performance and production of test

reports

OG10-R2.7 Functional / performance validation of any ADAM functionality or group of functionalities using the

Robot simulator

OG10-R3 The ground segment “mock-up” shall offer the capability to execute a plan in the following modes of

operation:

Simulation mode

Real execution mode

Replay mode using the data collected during a specific test

OG10-R4 The capabilities of the robotic vehicle shall be demonstrated in conditions that maximize the

representativeness with the targeted future missions (Moon, Mars):

OG10-R4.1 The terrain shall be selected to offer three different levels of difficulty (low, medium, high) in terms of:

(1) nature of soil, (2) density of obstacles, (3) slope in order to cover the variability of possible conditions.

The definition of the terrain characteristics range will be performed during the OG 10 Task 2.

OG10-R4.2 The lighting conditions during the tests shall cover the range of Sun incidences that can be encountered

during the execution of the mission plan. To be defined during the OG 10 Task 2.

OG10-R4.3 The vehicle morphology shall be representative from the shading standpoint (the presence of various

protuberances will produce shades which impact on some functionalities is to be considered)

OG10-R4.4 The representativeness level of the “objects of scientific interest” will have to be studied during the OG

10 Task 1 , taking into account the state of the art of the relevant techniques.

OG10-R4.5 The representativeness level of the instruments involved in the opportunistic science (detection, data

acquisition) will have to be studied during the OG 10 Task 1, taking into account the state of the art of the

relevant techniques.

8.7.3 Verification requirements

OG10-R5 The verification shall be performed in a step-wise manner:

Step 1: Simulation of the whole system using numeric models for the environment, the robot behaviour

(kinematic and dynamic) and the sensor outputs

Step 2: Outdoor testing with the real robot on a terrain with reduced size (ex: 10s of meters) – the objective

is to exercise the different capabilities and determine whether the robot is fit for more extensive testing

Step 3: Outdoor testing with the real robot on a full size terrain that includes the different categories of

difficulties listed above.

OG10-R6 The verification facilities shall include the means to assess the robot perception, localization, navigation

performances. This implies:

OG10-R6.1 Reconstruction of the 3D model of the environment – the objective is to get an accuracy 10 times better

than the performance of the rover perception system

OG10-R6.2 Localization of the vehicle in position and in attitude – the objective is to get an accuracy 10 times

better than the localization technique implemented on the robot

OG10-R7 The verification facilities shall include the means to assess the “opportunistic science” performances.

This implies:

OG10-R7.1 The autonomous detection of known targets of interest

OG10-R7.2 The assessment of their “scientific value”

OG10-R8 The verification process shall be designed to exercise the capabilities of autonomous decision making in

presence of conflicting objectives and assess the performances of the different functionalities involved in the

reconfiguration for scientific purpose:

OG10-R7.1 The assessment of the “science” activity cost (energy, time)

/73


Date 25/10/2017 Issue 1.6

OG10-R7.2 The update of the mission planning taking into account this new target, if required (depending on its

relative relevance and priority w.r.t. the initial mission)

OG10-R7.3 The update of the path planning taking into account this new target, if required (depending on its

relative relevance and priority w.r.t. the initial mission)

OG10-R7.4 The tracking of the target of interest – Note that this capability may rely on a functionality being used

also for localization during the traverse

OG10-R9 The verification facilities shall allow the storage of all data enabling the replay of the test scenario:

commands

robot sensor data

ground truth static and dynamic data.

definition of all reference frames (robot frame, beacon frame if any, sensor frame, …)

transformations between reference frames

OG10-R10 All dynamic data shall be time stamped with a common time origin and with a 10ms accuracy.

8.7.4 Implementation requirements:

OG10-R11 The design of the robotic system shall make a maximal re-use of the generic building blocks developed by the Call 1 Operational Grants

OG10-R12 The software of the robot and ground station shall be based on ESROCOS OG10-R13 The localization system should be based on sensors that belong to the I3DS sensor suite.

OG10-R14 The ADAM implementation shall be based on a processing architecture which computing power is

expected to be achievable by 2025 – 2030 timeframe.

/73


Date 25/10/2017 Issue 1.6

9 RESEARCH WORK AND DELIVERABLE DESCRIPTIONS FOR THE EXPLORING ROBOT-ROBOT INTERACTION (OG11)

The purpose of this section is to define the scope of the work on the Exploring robot-robot interaction for Operational

Grant 11, and its relationship to the other Operational Grants (1-5) from a systems integration approach.

9.1 Objectives

The challenge entrusted to this Operational Grant is to investigate and demonstrate the potential that robotic multi-agent

interaction can offer to future planetary exploration missions.

The rationale behind the use of multiple robotic agents is to overcome the limits in current space exploration activities,

mainly related to the adoption of a single mobile robotic agent, in order to increase robustness and scientific return from

a single mission.

Some of the advantages that derive from using multiple robotic agents in planetary missions could be summarized as

follow:

extended mission return, reducing the duration of each operation (i.e. surface exploration of pre-defined area)

extended mission operating spatial range, including hard-to-reach surface areas (being hazardous and too risky

for single robotic agent)

increased surface mapping detail and resolution through the use of data fusion techniques applied to

measurements generated by multiple rover explorers (e.g. combined 3D maps, etc.) and large baseline of

observations

improved mission robustness through an implicit redundancy of subsystems (i.e. imaging, communication, etc.)

and joint recovery procedures (e.g. removal of movement obstructions, mutual H/W inspection, etc.) in case of

faults or emergencies

enabling construction of complex infrastructures, such us habitation and ISRU plants, to prepare for human

planetary colonization

Moreover, such Operational Grant shall concretely demonstrate technology transfer possibilities between space-based

and terrestrial application, in order to:

spin-in approaches and concepts from terrestrial robotics sectors where multi-agent interaction is already at an

advanced level (e.g. mass-production industry, search and rescue, surveillance and security, robotic

competitions)

spin-out space-developed technologies and concepts to be implemented in terrestrial application with particular

emphasis on those performed in hard environments (i.e. agriculture and mining.)

/73


Date 25/10/2017 Issue 1.6

Figure 14. Examples of robot-robot interaction: robotic multi-agent autonomous surveillance of large

areas, on the left (source: SMProbotics4); football competition between autonomous robotic teams, on the right.

Robot-Robot Interaction (RRI) is based on the synchronized and organized acting of two or multiple robotic systems to

achieve a common purpose and implements the concepts of coordination and cooperation, as distinguished

hereafter:

Definition: “Coordination” identifies the process of organizing multiple agents/entities to work together or collaborate

properly and efficiently. This process explicitly implies a coordinated management of the single acting agents, both on

spatial and temporal level, and deals mainly with the sharing of resources.

Definition: “Cooperation” is the process of a group of autonomous organisms/entities working or acting together for a

common or mutual goal, without any hierarchical a-priori distribution of tasks and competences. The cooperation of

multiple vehicles requires the integration of sensing, control and planning in an appropriate collaborative decisional

architecture.

This OG shall focus exclusively on the investigation and demonstration of cooperative robot agents, as the subject of

coordination has been already extensively investigated in the past. Such activity shall lead to the development and

validation of a CREW module (Cooperative Robotics for Enhanced Workforce) which endows each robotic unit

with the following capabilities:

o Autonomous navigation and path planning

o Absolute and relative (i.e. wrt other robotic units) spatial localization

o Cooperative decision making and task execution

o Adaptation to task re-assignment

Proposals shall address one of the following alternative scenarios, in order to investigate the potential of multi-agent

robotic cooperation in a specific mission type:

OG11/a. Advanced mobility: The main challenge of this application scenario is to prove the potential of robot-robot

cooperation in the exploration of surface areas possibly very hard-to-reach, with the following constraints:

The demonstration shall be performed using existing robotic platforms or breadboard-level systems,

adapted/modified to achieve the needed functionalities.

The robotic platforms should be at least two units potentially endowed with diverse mobility solutions (e.g.

wheels, legs, caterpillars, etc.) and should be able to act together to undertake multiple descends/ascends into a

crater/gully or perform a joint surface mapping.

The cooperation investigated shall cover: 1) logical cooperation (in which the different agents are not interacting

physically with each other) 2) physical cooperation, in which the different agents interact logically and

mechanically to achieve the common goal

No hierarchical organization of the robotic team is required since each robotic agent shall be capable of

autonomous navigation and mutual coordination, i.e. definition of tasks to be performed.

4 http://smprobotics.com/

/73


Date 25/10/2017 Issue 1.6

The validation test should be performed in an analogue test environment (Lunar or Martian), preferably

outdoor, provided with craters/gullies and challenging slopes.

OG11/b. Robotized construction: The main goal of this application scenario is to demonstrate the potential of a

cooperating team of autonomous mobile robotic agents in the construction of basic infrastructure for habitation or

ISRU for future human colonization missions, with the following constraints:

The demonstration shall be performed using existing robotic platforms or breadboard-level systems,

adapted/modified to achieve the needed functionalities.

The robotic platforms should be at least two mobile robots equipped with robotic arms and diverse end-effectors,

in order to perform a minimum of site preparation activities, i.e. drilling, excavating and manipulation.

The cooperation investigated shall cover: 1) logical cooperation (in which the different agents are not interacting

physically with each other) 2) physical cooperation, in which the different agents interact logically and

mechanically to achieve the common goal

No hierarchical organization of the robotic team is required since each robotic agent shall be capable of

autonomous navigation and mutual coordination, i.e. definition of tasks to be performed.

The validation test should be performed within an analogue environment (Lunar or Martian), preferably in

outdoor test facilities.

Figure 15. Examples of robot-robot cooperation, addressing respectively (left) multi-agent cooperation in passing surface obstacles (source Swarm-Bots project); (right) robotic multi-agent cooperation in

lunar base construction (artist view).


The primary deliverable of this OG is a demonstrator of the potential that robotic multi-agent interaction can offer to

future planetary exploration missions. The demonstration is intended to be performed in a Martian or Lunar analogue

scenario and shall make use only of space-sized HW, i.e. OBS performances, power availability and storage, etc.

9.2.1 Definitions and system Breakdown

In detail, the demonstrator shall put together:

A set of Robotic Working Agents (RWA), each one composed of the following major subsystems:

CREW module: the brain that deals with autonomous and cooperative decision-making and action-

taking

a sensor suite composed with all sensors needed to fulfil required operations

a communication system for peer-to-peer information exchange and TC/TM sending with the

monitoring system

a locomotion system (wheels, legs, caterpillars, etc…)

a robotic arm and an end-effector/tool (if required)

/73


Date 25/10/2017 Issue 1.6

Figure 16: RWA functional subsystems diagram.

o A Testing Facility, made available by the OG consortium, equipped with: an analogue test environment, which would be representative of a planetary-like environment for

topological and lightning conditions constraints. an equipment suite providing ground truth (terrain model and robot reference localization)

A RWA Programming and Monitoring System, consisting of:

o An Environment Simulation Tool (EST), which is a specifically designed robot simulation software, essential to develop rapidly and test efficiently the robot control and cooperation algorithms, managing populations of RWAs in complex indoor or outdoor environments. Such EST shall be able to:

offer a topological and geometrical 3D representation of the test environment (3D Environment

Model)

implement a representative dynamic model of each RWA in terms of mobility and manipulation

capabilities

model the whole population of acting robotic agents

The EST shall implement the ESROCOS framework developed in Call 1 OG1 and can be integrated with

existing tools or libraries, i.e. GAZEBO, ARS, OpenRAVE, or others, if required.

o A Monitoring Station, developed within the OG, which would be responsible for monitoring the

tests, acquiring RWAs’ state telemetry and interfacing with the EST.

Figure 17: Overview of the collaborative robotic system to be developed.

/73


Date 25/10/2017 Issue 1.6


Within this OG11, the robotic system to be developed shall be able to clearly provide proof of cooperation between

multiple agents in performing specific operations, demonstrating capabilities and performances otherwise not achievable

with a single robotic agent.

To achieve this goal, the demonstration shall at least fulfil one of the following six sets of operations, depending on the

selected application scenario:

Advanced Mobility (OG11/a):

a.1. RAPPELLING ROBOTIC TEAM:

The suite of robots shall be able to cooperate together to pass very hard-to-reach surface areas, allowing

at least one of them to perform multiple descend/ascend in a crater or a gully (Lunar or Martian)

The suite of robots shall be able to approach autonomously the hard-to-reach area and to organize

themselves the descending/ascending procedure

a.2. EXPLORING ROBOTIC TEAM:

The suite of robots shall be able to act together to perform a cooperative exploration and a joint surface

mapping

At least one of the robots shall be qualified to move on unflatten surfaces, e.g. sloped surfaces, either

implementing an ad-hoc locomotion solution or changing its locomotion capability

a.3. JOINT-SCIENCE ROBOTIC TEAM:

The suite of robots shall be able to act together to perform cooperative science by use of simultaneous

measurements from different line-of-sight, such as atmospheric structure analysis (e.g. by using a

bistatic lidar or radar) or subsoil scanning (e.g. by use of geo-radar)

At least one of the robots shall be qualified to move on unflatten surfaces, e.g. sloped surfaces, either

implementing an ad-hoc locomotion solution or changing its locomotion capability

Robotic Construction (OG11/b):

b.1. SOIL-PREPARATION ROBOTIC TEAM:

The suite of robots shall be able to cooperate together to prepare the site for the construction of basic

infrastructures through the moving and grading of the soil. Excavating or drilling activities can be

performed to pose basement foundations for further structure assembly

The suite of robots shall be able to detect isolated obstacles, e.g. rocks, approach them and provide to

the removal from the interest area

b.2. ASSEMBLING ROBOTIC TEAM:

The suite of robots shall be able to cooperate together to assemble a 3D structure, starting from:

truss-like modules

regular modular elements, i.e. bricks

irregular elements, i.e. in-situ rocks

expandable/extensible subcomponents, e.g. packed in a compact configuration

The suite of robots shall be able to recover the assembling activity also in case of structural collapse, by

detecting scattered elements and their positioning

b.3. TRANSPORT ROBOTIC TEAM:

The suite of robots shall be able to cooperate together to handle and transport a large structure, i.e.

impossible to be handled by a single rover, on a complex terrain, e.g. with insulated obstacles, cracks

and sloped areas

/73


Date 25/10/2017 Issue 1.6

The suits of robots shall be able to interact and perform a closed chain control on mutual

torques/forces during target handling operation, in order to manage efficiently the loads

Multiple operations, addressing both application scenarios, can be performed during the demonstration.



the SRC is mandatory for OG11 in both the operative scenarios.

The Common Building Blocks must be integrated into the orbital support services application.

9.2.3.1 ESROCOS

The ESROCOS system shall be used as core operating system for each RWA, involved in the selected scenario. In detail,

ESROCOS shall be used in the following capacity:




9.2.3.2 ERGO

The ERGO Controller shall be used and configured so that each RWA is capable to perform its assigned operations and

manoeuvres, in relation to the selected scenario. In detail, ERGO shall be used for:

Cooperative task assignment, by communicating with other RWAs, planning and execution

RWA absolute and relative positioning

Path and trajectory planning during RWA’s manoeuvers

Execution and control of RWA’s manipulation activities (e.g. robot arm execution, end effector actuation)

9.2.3.3 InFuse

The InFuse Common Data Fusion Framework shall be used to create modelled maps of the robot’s situation, environment

and relative positions, in order to assist the robot’s decision making and planning with respect guidance, navigation and

control. In detail, the InFuse system shall be used to:

Create environmental maps, also by managing information provided by other RWA

Provide single RWA controller with information about its absolute and relative positioning

Provide images or advanced data from specific sensors (e.g. during manipulation activities or navigation)

9.2.3.4 I3DS

The I3DS Sensor Suite (i.e. set of sensors and Instrument Control Unit) shall be adopted as basic model for the sensor

suite implementation on-board each RWA. In detail, the I3DS control unit (ICU) shall be adopted as reference kernel for

the management and control of each set of sensors, in order to:

Provide centralization and pre-processing of certain sensor data output

Provide the RWA controller and its data fusion framework with all information needed to make decisions,

concerning:

o Manipulation


Furthermore each RWA will need sensors that should be selected out of the I3DS suite of sensors, unless it is shown that

the latter cannot fulfil the scenario requirements.



/73


Date 25/10/2017 Issue 1.6

9.2.3.5 SIROM Interface

The SIROM connector shall be used as standard hardware interface and between couplings points. SIROM shall also be

used as the point of interface upon the RWA itself.

The SIROM connector shall then be used to:

Interconnect APMs, e.g. assembling modules, if required by the specific operative scenario

Connect an end-effector with the robotic arm, on-board the RWA

Connect two RWAs, if required by the specific operating scenario

9.3 Work Logic

The Work Logic scheme is common to all the OGs and it is reported in chapter 4. The shown block diagram highlights the

integrated flow from technology review and system requirements definition up to the final demonstration and acceptance.











The activities related to the coordination within and outside the Consortium are detailed in section 9.5.3.



OG11 shall be responsible for the central maintenance of OG3 InFuse data fusion software framework, in

addition to its implicit upgrade in order to fulfil required multi-agent capabilities.

This means OG11 shall:


Be the point of contact for disseminating and receiving new code, addendums and features of the InFuse

framework, from other OGs




The Technology Review shall assess the state-of-the-art as well as the products being developed by OG1-5

The review shall address differing potential methods of achieving the overarching objective of OG11, within the selected

operative scenario, so that the pros and cons of each method may be properly understood.







/73


Date 25/10/2017 Issue 1.6

The review shall define how these products will be used, further developed or adapted to suit the task at hand.






data requirements

S/W requirements




The System Requirements as described in §5.4.2 will form the basis for the preliminary design of the multi-agent robotic

suite, equipment and tools needed for the demonstration.

Task 2 will therefore comprise the following actions:






suit this OG.










Within this task the detailed definition of the robotic system to be integrated and a description of the demonstration

scenario are addressed.

To complete this task, the consortium must complete and collate the following individual activities:

Definition and Design of the robotic system, providing a detailed description of the activities required to

realize each unit and to integrate it, both in terms of robots suite and monitoring system

Definition of the activities required for the adaptation and implementation of the products developed in

Call 1’s OGs 1-5

Definition and Design of the demonstration scenario, in terms of analogue environment characteristics and

required testing equipment

Definition of the demonstration goals, schedule and procedures

The detailed design will be captured in dedicated deliverable documents, which is to be presented for review at the CDR,

as stated in §5.

The results of the task shall be documented in a dedicated deliverable document and in a dedicated branch of the GIT

repository.

/73


Date 25/10/2017 Issue 1.6



demonstration of the sought multi-agent robotic suite. This task takes as input the results of the CDR to provide the final,

integrated model of the demonstrator as fully functional representative of planetary scenario.

At the end of this task it shall be possible to immediately initiate the demonstration tests.

Therefore, the task shall at least include the following individual activities:








documentation)

The demonstrator is to be presented for review at the TRR, as stated in §4.




and analysis of data to validate the implementation of the multi-agent robotic suite or assess any non-conformance.


The task shall be concluded with a Final Acceptance (FA) and Demonstration Event, that shall provide proof that the

reference implementation meets specifications and achieves expected objectives, as stated in §4.

9.5 Programmatics

9.5.1 Schedule

The OG will run according to the sequence of tasks stated at chapter 4. The OG is required to report periodically and

present the results during meetings and reviews (milestones) in certain time steps.

Some of the milestones of the OG are however in common for all the OGs in the SRC. The precise date of these common


9.5.2 Duration


9.5.3 Management


The Consortium of the OG has to make sure all meetings outlined in Table 10 are going to be organised in time.


Meetings with other OG Consortia can also be organised as-needed.




/73


Date 25/10/2017 Issue 1.6



9.5.4 Reporting


months a progress report, that records


updated schedule

action item list

the exploitation plan based on the results gained since T0









each submission.

Every presentation given within the Operational Grant has to be submitted in the Microsoft PowerPoint (PPT or PPTX)





KO Kick-Off T0






Final Presentation T0+24 months


The Consortium is expected to establish additional Progress Meetings, with the frequency of 1 every 2 months, when not

in combination with Milestone events, open to the participation of the PSA.

9.6 Deliverables

9.6.1 General



9.6.2 Documentation



/73


Date 25/10/2017 Issue 1.6




Table 11. Core deliverables required for OG11



Cluster:






In this section a set of basic requirements are defined in order to assure the final achievement of the OG goals and a

complete and efficient matching with the Call 1 results.


Each mobile Robotic Working Agent (RWA), involved in the robotic system to be developed, shall be able to

provide the following basic functionalities:

OG11-R01 Motion execution and feedback control

OG11-R02 Autonomous path planning, including obstacle detection and avoidance

OG11-R03 Absolute and relative spatial localization, also by use of sensor data fusion capabilities

OG11-R04 Autonomous power resource management

OG11-R05 Communication and data exchange with other robotic agents and the Monitoring Station

OG11-R06 Manipulation/handling capabilities, in relation to the operative scenario, and feedback control


OG11-D1-System Requirement Document

SRD

SRR PU

OG11-D2-Preliminary Design Document

(PDD)

PDR PU






OG11-D8-Videos FA PU



OG11-D11-Final report and Final

Presentation

FA, PU

OG11-D12- Technology development plan SRR, updated at CDR, finalised at FA CO-1

OG11-D13- Dissemination plan SRR, updated at CDR, finalised at FA PU

OG11-D14-Exploitation plan SRR, updated at CDR, finalised at FA CO-1

/73


Date 25/10/2017 Issue 1.6

OG11-R07 Implementation of FDIR procedures on case of anomalous behaviours or critical situations

The Monitoring Station, in the framework of the RWA Programming and Monitoring System, shall be able to

provide the following functionalities:

OG11-R08 Launch of the demonstration plan and monitoring of the tasks execution

OG11-R09 Collection and storage of the operative data of the whole demonstration campaign

OG11-R10 Monitoring of the operative status of the whole robotic suite by receiving TM data from each

RWA

OG11-R11 Detection of criticalities and anomalous situations (e.g. risk of task failure, risk of robot failure

or damaging) and automatic implementation of recovery procedures

The Environment Simulation Tool, in the framework of the RWA Programming and Monitoring System, shall be

able to provide the following functionalities:

OG11-R12 Simulation of the operative behaviour of each RWA, by implementing its kinematic and

dynamic model

OG11-R13 Test CREW module performances and functionalities, once coupled with the kinematic and

dynamic model of each RWA

OG11-R14 Simulation of the whole demonstration sequence, ahead the real execution, to validate the

procedure and detect criticalities in the cooperative logics of RWAs

OG11-R15 Video reconstruction of the performed test by use of acquired data


The following set of requirements shall be taken into account during the design, development and integration of the

robotic system, in terms of HW/SW components:

OG11-R16 The design of the system shall maximize the re-use of common building blocks developed by

Call1 Operational Grants (OG 1-5), namely:

OG1 – ESROCOS

OG2 – ERGO

OG3 – InFuse

OG4 – I3DS

OG5 – SIROM

OG11-R17 The robotic system, including the mobile agents and the supervisor station, shall be based on

OG1–ESROCOS operative system

OG11-R18 Each RWA shall be provided of autonomy capabilities by use of OG2 – ERGO controller

OG11-R19 The localization and navigation system of each RWA shall use data provided by a sensor suite

similar to the OG4’s one, equipped with a minimal combination of instruments among which:

Exteroceptive sensors:

Stereo camera imaging system

Laser range finder

Close-Up Hi-Res cameras

Narrow/wide angle radars

ToF cameras

Ultrasound sensors

Contact sensors

Proprioceptive sensors:

Inertial Measurement Unit (IMU)

/73


Date 25/10/2017 Issue 1.6

Force/torque sensors

Wheel encoders/odometers

OG11-R20 Each robotic agent shall implement sensor data fusion capabilities inherited from the OG3 -

InFuse product

9.7.2 Verification Requirements

The V&V of the robotic system shall be performed in a step-wise manner:

OG11-R21 Step 1: Simulation of the single RWA operative behaviour by use of the kinematic and dynamic

model of the robotic platform and the numeric environmental model, within the Environment

Simulation Tool.

OG11-R22 Step 2: Indoor or outdoor testing of the single RWA in order to correlate experimental data

with simulation results and validate the functionalities and performances of each RWA. The

verification of the Monitoring Station, wrt the single RWA, shall be also performed.

OG11-R23 Step 3: Simulation of expected operations performed by the complete robotic team within the

Environment Simulation Tool, by use of kinematic and dynamic models of RWAs and numeric

reconstruction of the test environment, in order to validate the cooperative logics of the

system.

OG11-R24 Step 4: Outdoor testing of the complete physical robotic system in order to correlate

experimental data and task execution with simulation results and validate the implemented

multi-agent cooperation logics.

OG11-R25 Step 5: Outdoor final demonstration of the developed robotic system in order to give proof of

the successful achievement of the OG goals.

In order to achieve a robust and complete verification of the robotic system, the selected testing facilities shall provide:

OG11-R26 An analogue environment fully representative of the mission scenario, in terms of

a. nature of terrain, i.e. lunar or martian, in terms of soil granularity

b. surface flatness and maximum angle of sloped regions

c. density and dimension of isolated obstacles, i.e. rocks

d. slope and depth of extended surface discontinuities, i.e. craters or gullies, if required

by the selected demonstration

e. lighting conditions, wrt different Sun incidences encountered during the mission

execution

OG11-R27 A numeric 3D model of the real analogue environment

OG11-R28 A localization system, to be adopted as reference, able to define with precision the attitude and

position of each RWA, wrt testing environment