SPACE-12-TEC Guidance Document for. Horizon 2020 Work Programme Final

Transcription

1 Strategic Research Cluster: Space Robotics Technologies SPACE-12-TEC-2018 Guidance Document for Horizon 2020 Work Programme Final 25/10/2017

2 Report D3.2-Compendium of SRC activities (for call 2) 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 Lead Beneficiary Lead Author Authors Status Dissemination Level WP3/ Task T3.1 Master Planning European Space Agency Gianfranco Visentin Daniel Noelke, Michel Delpech, Sabine Moreno, Roberto Bertacin, Javier Rodriguez, Daniel Jones Final Public This project has received funding from the European Union s Horizon 2020 research and innovation programme under grant agreement No 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. Page 1/73

3 Title 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) /05/2017 Main products and deliverables define 0.2 7/06/2017 Work logic and milestones /06/2017 Detailing /06/2017 Detailing 0.5 2/07/2017 Detailing /09/2017 Detailing /09/2017 Harmonisation /09/2017 Harmonisation /09/2017 Harmonisation /09/2017 Harmonisation /10/2017 Formatting /10/2017 Issue 1.6 Reason for change Date Pages Paragraph(s) Fixing of inconsistencies and formatting 03/11/2017 all all Page 2/73

4 Table of Contents Applicable Documents... 7 REFERENCE Documents... 7 Acronyms and Definitions Introduction Objectives of the document Topic of the 2018 Call General Challenge Application: Orbital Support Service (OG7) Application: Robotised Assembly Of Large Modular Orbital Structures (OG8) Application: Robotised Reconfiguration Of Satellites (OG9) Application: Autonomous Decision Making (OG10) in very long traverses Application: Exploring Robot-Robot Interaction (OG11) in planetary exploration and exploitation 10 3 Reuse of common building blocks Maintenance of Call 1 Building Blocks Common Work Logic in the Operational Grants Research Work and Deliverable Descriptions for THE Orbital support services (OG7) Objectives Work description Definitions and System Breakdown Description of Operations Reuse of Call 1 building blocks Work Logic Task Descriptions Task 0: Technical management Task 1: Technology Review, System Requirements Task 2: Preliminary Design and Modelling Task 3: Detailed Design of Demonstrator and related test setup Task 4: Manufacturing, Assembly and Integration of demonstrator and test equipment Task 5: Execution of test, demonstration and correlation of test results Programmatics Schedule Duration Management Reporting Milestones and Meetings Deliverables General Documentation Hardware and Software Deliverables ANNEX 1 USER Requirements Functional Requirements Page 3/73

5 5.7.2 Implementation Requirements Research Work and Deliverable Descriptions for the robotised assembly of large modular orbital structures (OG8) Objectives Work Description Definitions and System Breakdown Reuse of Call 1 Building Blocks Work Logic Task Descriptions Task 0: Technical management Task 1: Technology Review, System Requirements Task 2: Preliminary Design and Modelling Task 3: Detailed Design of Demonstrator and related test Setup Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment Task 5: Execution of test, demonstration and correlation of test results Programmatics Schedule Duration Management Reporting Milestones and Meetings Deliverables General Documentation Hardware and Software Deliverables ANNEX 2 USER Requirements Definitions and Product Tree Functional Requirements Implementation Requirements Research Work and Deliverable Descriptions for the robotised reconfiguration of satellites (OG9) Scope Work description Definitions and System Breakdown Description of Operations Reuse of Call 1 building blocks Work Logic Task Descriptions Task 0: Technical management Task 1: Technology Review, System Requirements Task 2: Preliminary Design and Modelling Task 3: Detailed design of Demonstrator and related test setup Task 4: Manufacturing, Assembly and Integration of demonstration and test equipment Task 5: Execution of test, demonstration and correlation of test results Programmatics Schedule Page 4/73

6 7.5.2 Duration Management Reporting Milestones and Meetings Deliverables General Documentation Hardware and Software Deliverables ANNEX - User Requirements Functional Requirements Implementation requirements Verification requirements Research Work and Deliverable Descriptions for the autonomous decision making (OG10) Objectives Work description Assumptions to be considered for the study Reuse of Call 1 building blocks Work Logic Task Descriptions Task 0: Technical management Task 1: Technology Review, System Requirements Task 2: Preliminary Design and Modelling Task 3: Detailed design of Demonstrator and related test setup Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment Task 5: Execution of test, demonstration and correlation of test results Programmatics Schedule Duration Management Reporting Milestones and Meetings Deliverables General Documentation Hardware and Software Deliverables ANNEX 4 USER Requirements Definitions and Deliverable Tree Functional requirements: Verification requirements Implementation requirements: Research Work and Deliverable Descriptions for the exploring robot-robot interaction (OG11) Objectives Work description Definitions and system Breakdown Page 5/73

7 9.2.2 Description of Operations Reuse of Call 1 building blocks Work Logic Task Descriptions Task 0: Technical management Task 1: Technology Review, System Requirements Task 2: Preliminary Design and Modelling Task 3: Detailed design of Demonstrator and related test setup Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment Task 5: Execution of test, demonstration and correlation of test results Programmatics Schedule Duration Management Reporting Milestones and Meetings Deliverables General Documentation Hardware and Software Deliverables ANNEX 5 USER Requirements Functional Requirements Implementation Requirements Verification Requirements Page 6/73

8 APPLICABLE DOCUMENTS Source Document Link OG1 Design Definition Document Interface Control Document OG2 Design Definition Document Interface Control Document OG3 Design Definition Document Interface Control Document OG4 Design Definition Document Interface Control Document OG5 Design Definition Document Interface Control Document PSA Integrated Interface Control Document SRC Roadmap EC Call Text EC Participant portal REFERENCE DOCUMENTS Source Document Link ESA ASSIST Standardisation File Document Page 7/73 Date 31/10/ :13:00 Issue 1.6

9 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 Page 8/73

10 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 highperformance 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 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. Page 9/73

11 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. Page 10/73

12 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-andreact 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 Page 11/73

13 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. Page 12/73

14 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. Page 13/73

15 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 Page 14/73

16 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 Page 15/73

17 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 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 Page 16/73

18 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. a sensor suite equipped with all necessary sensors to fulfil its purpose, based on I3DS 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 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. Page 17/73

19 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 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. Page 18/73

20 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 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 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 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 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. Page 19/73

21 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 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 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 Ensure any changes in functionality are captured in the user guidelines to help with use, troubleshooting, etc 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. Page 20/73

22 5.4.3 Task 2: Preliminary Design and Modelling The System Requirements as described in 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 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 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 Page 21/73

23 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 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 Programmatics 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 Duration The total duration of this Operational Grant is 24 months from the Kick-Off (T0) 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 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: Page 22/73

24 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 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 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 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. Page 23/73

25 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 CO-1 FA OG7-D13- Dissemination plan SRR, updated at CDR, finalised at PU FA OG7-D14-Exploitation plan SRR, updated at CDR, finalised at CO-1 FA Table 3: Core deliverables required for OG 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 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.) 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. Page 24/73

26 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. Page 25/73

27 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 state 1. 1 L. D. Feinberg et al., Modular assembled space telescope, Opt. Eng.52(9), (2013) Page 26/73

28 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. Page 27/73

29 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 Definitions and System Breakdown 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 a sensor suite equipped with all necessary sensors to fulfil its purpose, based on I3DS 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). st_report_final_ pdf Page 28/73

30 o o o o o A control/communication node based on the ERGO via the ESROCOS framework An individual mirror Internal actuators to enable individual positioning of the mirror position sensors enabling accurate localisation of the tile 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 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 OG8. The Common Building Blocks must be integrated into the Robot Assembly System and play a functional role in achieving the stated objectives 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: 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 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 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 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) Page 29/73

31 o Mobility (movement, attitude, state, localisation) OG8 is expected to reproduce/procure all the elements of I3DS needed for the work in OG 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 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. 6.4 Task Descriptions 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 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 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 Ensure any changes in functionality are captured in the user guidelines to help with use, troubleshooting, etc Task 1: Technology Review, System Requirements 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. 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: Page 30/73

32 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 Task 2: Preliminary Design and Modelling The System Requirements deliverable as described in will form the basis for the preliminary design of the Robotised Mirror 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 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 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: Page 31/73

33 Coding of the required control software and test Preparation of required support equipment 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) Any documentation produced by the task shall be uploaded in the GIT repository. The demonstrator is to be presented for review at the TRR, as stated in 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 the Robotic Assembly System and Mounted Mobility System, 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 robotised assembly operation (from RvD to detach) are to be presented, as stated in Programmatics 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 Duration The total duration of this Operational Grant is 24 months from the Kick-Off (T0) 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 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. 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 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 Page 32/73

34 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: 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 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 and Final Presentation T0+24 months Table 4: Milestones required for OG8 6.6 Deliverables 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 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 5 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 OG8 Consortium, these documents shall have CO-1 access rights. Page 33/73

35 Deliverable When Access Rights OG8-D1-System Requirement Document SRD SRR PU OG8-D2-Preliminary Design Document (PDD) PDR PU OG8-D3-Test/Demonstration Specification PDR PU OG8-D4-Demonstration Procedures CDR PU OG8-D5-Detailed Design Document DDD CDR PU OG8-D6-Software manual FA PU OG8-D7-Test/Demonstration Report FA PU OG8-D8-Videos FA PU OG8-D9-Datasets FA PU OG8-D10-Publications FA PU OG8-D11-Final report and Final Presentation FA, PU OG8-D12- Technology development plan SRR, updated at CDR, finalised at CO-1 FA OG8-D13- Dissemination plan SRR, updated at CDR, finalised at PU FA OG8-D14-Exploitation plan SRR, updated at CDR, finalised at FA CO-1 Table 5 Core deliverables required for OG 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 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 ANNEX 2 USER Requirements Definitions and Product Tree The definitions provided at 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 Page 34/73

36 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. Page 35/73

37 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 Functional Requirements 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 Implementation Requirements 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 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. Page 36/73

38 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 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 reuse 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 Page 37/73

39 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. 7.2 Work description 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 Definitions and System Breakdown 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 Page 38/73

40 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 Page 39/73

41 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 Description of Operations 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: 1 st 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. 2 nd 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) Reuse of Call 1 building blocks 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 Page 40/73

42 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 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 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 InFuse The platform shall implement sensor data fusion techniques from OG3 applied to self-provided measurements (i.e. provided by its equipped sensors) 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 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 OG 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. Page 41/73

43 7.4 Task Descriptions 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, if necessary with the Programme Support Activity of the SRC The activities related to the coordination within and outside the Consortium are detailed in section 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 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 Integrate any changes or new features with the central version Ensure any changes in functionality are captured in the user guidelines to help with use, troubleshooting, etc Task 1: Technology Review, System Requirements 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 The review shall address differing potential methods of achieving the overarching objective of OG9, 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 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. 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)? Page 42/73

44 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? Task 2: Preliminary Design and Modelling The System Requirements as described in 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 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 The design shall be recorded in the GIT repository 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 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 Task 4: Manufacturing, Assembly and Integration of demonstration and test equipment The task shall include all manufacturing/coding/procurement, integration and testing activities needed to produce the 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. 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 Page 43/73

45 Preparation of required support equipment 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) 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 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 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 are to be presented, as stated in Programmatics 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 Duration The total duration of this Operational Grant is 24 months from the Kick-Off (T0) 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. 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. Page 44/73

46 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 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 (at least) 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: a final dissemination report and an exploitation plan 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 Milestones and Meetings 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 FA Final Acceptance and Final Presentation T0+24 months Table 6: Milestones required for OG9 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. 7.6 Deliverables 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 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 7 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 OG9 Consortium, these documents shall have CO-1 access rights. Page 45/73

47 Deliverable When Access Rights OG9-D1-System Requirements Document SRR PU (SRD) OG9-D2-Preliminary Design Document (PDD) PDR PU OG9-D3-Test/Demonstration Specification PDR PU OG9-D4-Demonstration Procedures CDR PU OG9-D5-Detailed Design Document (DDD) CDR PU OG9-D6-Software manual FA PU OG9-D7-Test/Demonstration Report FA PU OG9-D8-Videos FA PU OG9-D9-Datasets FA PU OG9-D10-Publications FA PU OG9-D11-Final report and Final Presentation FA PU OG8-D12-Technology development plan SRR, updated at CDR, finalised at CO-1 FA OG9-D13-Dissemination plan SRR, updated at CDR, finalised at PU FA OG9-D14-Exploitation plan SRR, updated at CDR, finalised at CO-1 FA Table 7: Core deliverables required for OG 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 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. 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 Functional Requirements 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 Page 46/73

48 OG9-R04 OG9-R05 OG9-R05.1 OG9-R06 OG9-R07 OG9-R08 OG9-R09 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. The platform shall be able to reconfigure and use new functionalities brought by additional functional modules The platform functionality of the satellite shall be upgraded by functional modules The platform shall be able to monitor the status of essential parameters of each connected functional module 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) The system shall be able to handle the described scenario even during a connection failure or a power interruption of defect modules/interconnectors. 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 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 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. Page 47/73

49 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 1 st call of the SRC, that is to say on the building blocks delivered by the OGs of the 1 st call. Page 48/73

50 Figure 11 Example of scenario combining manually and autonomously targeted scientific site of interest 8.2 Work description 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 Page 49/73

51 Figure 12 Preliminary architecture of the ADAM 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 Reuse of Call 1 building blocks 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 Page 50/73

52 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 / unplugging task. This Operational Grant shall implement the building blocks developed during previous SRC s phase, namely OG1-5, addressing in detail 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: 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 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 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 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. OG10 is expected to reproduce/procure the elements of I3DS sensor suite needed for the work in OG10. In addition, it is not excluded to revisit the architecture of the I3DS ICU if an alternate design appears relevant 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. Page 51/73

53 8.4 Task Descriptions 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 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 OG10 shall be responsible for the central maintenance of OG2 ERGO autonomy framework. This means OG10 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 ERGO framework Integrate any changes or new features with the central version Ensure any changes in functionality are captured in the user guidelines to help with use, troubleshooting, etc Task 1: Technology Review, System Requirements 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 review shall address differing potential methods of achieving the overarching objective of OG10, so that the pros and cons of each method may be properly understood. OG1 The ESROCOS operating system OG2 The ERGO Controller OG3 The InFuse Data Fusion system OG4 The I3DS sensor suite the review shall define how these products will be used, further developed or adapted to suit the task at hand 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 Following the technology survey, System Requirements shall be identified, in terms of: Page 52/73

54 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 Task 2: Preliminary Design and Modelling The System Requirements as described in will form the basis for the preliminary design of the autonomy module and its ground station. 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 Task 3: Detailed design of Demonstrator and related test setup 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 The results of the task shall be documented in a dedicated deliverable document and in a dedicated branch of the GIT repository Task 4: Manufacturing, Assembly and Integration of reference implementation and test equipment The task shall include all manufacturing/coding/procurement, integration and testing activities needed to produce the 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. Page 53/73

55 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 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. shall be uploaded in the GIT repository 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 Programmatics 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 milestones will be determined by the SRC Board, established following the Collaboration Agreement Duration The total duration of OG is 24 months from the kick-off 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 table (marked with OGx-con ) 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. 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 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 Page 54/73

56 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: 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 Milestones and Meetings 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 FA Final Acceptance and Final Presentation T0+24 months Table 8: Milestones required for OG10 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. 8.6 Deliverables 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 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 9 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 OG10 Consortium, these documents shall have CO-1 access rights. Page 55/73

57 Deliverable When Access Rights OG10-D1-System Requirement Document SRR PU SRD OG10-D2-Preliminary Design Document PDR PU (PDD) OG10-D3-Test/Demonstration Specification PDR PU OG10-D4-Demonstration Procedures CDR PU OG10-D5-Detailed Design Document DDD CDR PU OG10-D6-Software manual FA PU OG10-D7-Test/Demonstration Report FA PU OG10-D8-Videos FA PU OG10-D9-Datasets FA PU OG10-D10-Publications FA PU OG10-D11-Final report and Final Presentation FA, PU OG10-D12- Technology development plan SRR, updated at CDR, finalised at CO-1 FA OG10-D13- Dissemination plan SRR, updated at CDR, finalised at PU FA OG10-D14-Exploitation plan SRR, updated at CDR, finalised at FA CO-1 Table 9: Core deliverables required for OG10 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 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 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. 8.7 ANNEX 4 USER Requirements 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) Page 56/73

58 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 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 Page 57/73

59 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 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) Page 58/73

60 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 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 timeframe. Page 59/73

61 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.) Page 60/73

62 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 Page 61/73

63 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). 9.2 Work description 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 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 actiontaking 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) Page 62/73

64 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. Page 63/73