facilitators interface control document€™s kuka robotic arm ... figure 3-8: kuka kr 150-2 flange...

Prepared by: FACILITATORS team

Approved by: Matteo Suatoni

Authorized by: Pablo Colmenarejo

Code: GMV-FACILITATORS-D2.1

Version: 1.1

Date: 19/10/2017

Internal code: GMV 20785/17 V2/17

GMV, 2017; all rights reserved

FACILITATORS INTERFACE

CONTROL DOCUMENT FACILITATORS

Code:

Date:

Version:

Page:

FACILITATORS GMV 2017; all rights reserved FACILITATORS INTERFACE CONTROL DOCUMENT

GMV-FACILITATORS-D2.1

19/10/2017

1.1

2 of 61

Code:

Date:

Version:

Page:



19/10/2017

1.1

3 of 61

DOCUMENT STATUS SHEET

Version Date Pages Changes

1.0 20/06/2017 57 First Version of the document

1.1 19/10/2017 61 Updates after RIDs from PDR:

JIRA OG6-74: updates in 3.3.1

JIRA OG6-75: updates in 3.3.4 accordingly to OG4 validation plan.

JIRA OG6-76: the list of sensors and how they are tested has been updated

in 3.3.1 accordingly with OG4 validation plan.

Update in 3.2.3.3 for RID OG6-OG2-O-OR-02 in “OG6 PSA RIDs.xls”.

Update in 3.1.2.1 for RID in “OG6 PSA RIDs.xls”.

JIRA OG6-82: OBC for OG1 tests have been selected, updates in 3.2.3.3 and

6.1.1.

Addition of SherpaTT API description in 5.1.2, as per RID row 12 of “OG6

PSA RIDs.xls”

Removed OG5-OG6/F/007/002/V0.1 in 4.3.3 as per RID 14 of “OG5-OG6

PDR RIDs from OG5.xls”

Updates in in 4.3.3 as per RID 22 of “OG5-OG6 PDR RIDs from OG5.xls”.

Updates in 4.1 taking into account last strategy agreed with OG3.

JIRA OG6-63 and OG6-81: Updates of OG5 diagrams and text in 4.3.

Updates in 4.3 due to RIDs of line 32 and 35 of “OG6 PSA RIDs.xls” and for

accounting the issues of “GMV-FACILITATORS-PDR_MoM_with_splinters”

Annex 3, and SIROM_PDR-Madrid_MoM_OG5_OG6.

Updates in 4.3 for RID OG3 General of “OG6 PSA RIDs.xls” and for taking

into account agreements between OG6 and OG3.

Updates in 5.1 and 5.2 for RIDs in “OG5-OG6 PDR RIDs.xls”

Code:

Date:

Version:

Page:



19/10/2017

1.1

4 of 61

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................................ 8

1.1. PURPOSE ................................................................................................................................ 8

1.2. SCOPE .................................................................................................................................... 8

1.3. DISSEMINATION LEVEL OF THIS DOCUMENT ............................................................................. 8

1.4. ACRONYMS ............................................................................................................................. 8

2. REFERENCES .................................................................................................................................. 10

2.1. APPLICABLE DOCUMENTS ...................................................................................................... 10

2.2. REFERENCE DOCUMENTS ....................................................................................................... 10

3. GMV FACILITIES ............................................................................................................................. 11

3.1. OG1 ORBITAL VALIDATION FACILITIES ................................................................................... 11 3.1.1. DESCRIPTION ................................................................................................................................. 11 3.1.2. HW INTERFACES ............................................................................................................................. 13

3.1.2.1. On Board Computer ............................................................................................. 13 3.1.2.2. Camera .............................................................................................................. 13 3.1.2.3. Robotic arm ........................................................................................................ 13 3.1.2.4. Monitors............................................................................................................. 13 3.1.2.5. Connections........................................................................................................ 13

3.1.3. DATA INTERFACES .......................................................................................................................... 14 3.1.4. TEST INPUTS/OUTPUTS ................................................................................................................... 16

3.1.4.1. Inputs................................................................................................................ 16 3.1.4.2. Outputs ............................................................................................................. 16 3.1.4.3. Parameters ......................................................................................................... 16

3.2. OG2 ORBITAL VALIDATION FACILITIES ................................................................................... 17 3.2.1. DESCRIPTION ................................................................................................................................. 17 3.2.2. HW INTERFACES ............................................................................................................................. 19

3.2.2.1. Power interfaces ................................................................................................. 19 3.2.2.2. Data connection .................................................................................................. 19

3.2.3. SW INTERFACES ............................................................................................................................. 19 3.2.3.1. Visual navigation link ........................................................................................... 19 3.2.3.2. Arm motion planner link ....................................................................................... 19 3.2.3.3. GNC link ............................................................................................................ 20 3.2.3.4. Synchronisation link ............................................................................................ 20

3.2.4. TEST INPUTS/OUTPUTS ................................................................................................................... 20 3.2.4.1. Inputs................................................................................................................ 20 3.2.4.2. Outputs ............................................................................................................. 20 3.2.4.3. Parameters ......................................................................................................... 20

3.3. OG4 ORBITAL VALIDATION FACILITIES ................................................................................... 22 3.3.1. HIGH LEVEL DESIGN ....................................................................................................................... 22 3.3.2. HW INTERFACES ............................................................................................................................. 24

3.3.2.1. Power/electrical Interface ..................................................................................... 24 3.3.2.2. Mechanical Interfaces .......................................................................................... 24

3.3.2.2.1. Mounting of I3DS sensors suite box ............................................................. 24 3.3.2.2.2. Interface for Facility Calibration Retroreflectors ............................................. 25

3.3.2.3. Mock-up interfaces .............................................................................................. 26 3.3.2.4. Synchronization link ............................................................................................ 26

3.3.3. DATA INTERFACE ............................................................................................................................ 26 3.3.3.1. Synchronization link packet .................................................................................. 26

Code:

Date:

Version:

Page:



19/10/2017

1.1

5 of 61

3.3.4. TEST INPUTS/OUTPUTS PARAMETERS ............................................................................................... 26 3.3.4.1.1. Inputs ...................................................................................................... 26 3.3.4.1.2. Outputs .................................................................................................... 26 3.3.4.1.3. Parameters ............................................................................................... 27

4. DLR FACILITIES .............................................................................................................................. 28

4.1. OG3 PLANETARY VALIDATION FACILITIES ............................................................................... 28 4.1.1. HIGH LEVEL DESIGN (DESCRIPTION)................................................................................................ 28 4.1.2. OG3-OG6 INTERFACES OF PLANETARY TRACK................................................................................... 31 4.1.3. OPERATIONAL INTERFACES .............................................................................................................. 31 4.1.4. FUNCTIONAL INTERFACES ............................................................................................................... 31 4.1.5. POWER INTERFACES ........................................................................................................................ 31 4.1.6. MECHANICAL INTERFACES ............................................................................................................... 32 4.1.7. DATA INTERFACES ........................................................................................................................... 32 4.1.8. TEST INPUTS/OUTPUTS.................................................................................................................... 33

4.1.8.1. Inputs ................................................................................................................ 33 4.1.8.2. Outputs ............................................................................................................. 33 4.1.8.3. Parameters ......................................................................................................... 33

4.2. OG3 ORBITAL VALIDATION FACILITIES ................................................................................... 34 4.2.1. OG3-OG6 INTERFACES OF ORBITAL TRACK ....................................................................................... 35 4.2.2. OPERATIONAL INTERFACES .............................................................................................................. 35 4.2.3. FUNCTIONAL INTERFACES ............................................................................................................... 35 4.2.4. POWER INTERFACES ........................................................................................................................ 35 4.2.5. MECHANICAL INTERFACES ............................................................................................................... 35 4.2.6. DATA INTERFACES ........................................................................................................................... 35 4.2.7. SOFTWARE INTERFACES .................................................................................................................. 36 4.2.8. TEST INPUTS/OUTPUTS.................................................................................................................... 36


4.3. OG5 ORBITAL VALIDATION FACILITIES ................................................................................... 37 4.3.1. OG5-OG6 INTERFACES OF ORBITAL TRACK ....................................................................................... 38 4.3.2. OPERATIONAL INTERFACES .............................................................................................................. 38 4.3.3. FUNCTIONAL INTERFACES ............................................................................................................... 39 4.3.4. POWER INTERFACES ........................................................................................................................ 40 4.3.5. MECHANICAL INTERFACES ............................................................................................................... 40 4.3.6. DATA INTERFACES ........................................................................................................................... 42 4.3.7. SOFTWARE INTERFACES .................................................................................................................. 43 4.3.8. TEST INPUTS/OUTPUTS.................................................................................................................... 43


5. DFKI FACILITIES ............................................................................................................................. 45

5.1. OG2 PLANETARY VALIDATION FACILITIES ............................................................................... 45 5.1.1. DESCRIPTION .................................................................................................................................. 45 5.1.2. FUNCTIONAL INTERFACES ............................................................................................................... 47 5.1.3. HW INTERFACES.............................................................................................................................. 49

5.1.3.1. Power interfaces ................................................................................................. 49 5.1.3.2. Mechanical interfaces ........................................................................................... 49

5.1.4. DATA INTERFACES ........................................................................................................................... 49 5.1.5. TEST INPUTS/OUTPUTS.................................................................................................................... 50

5.1.5.1. Inputs ................................................................................................................ 50 5.1.5.2. Outputs ............................................................................................................. 50

Code:

Date:

Version:

Page:



19/10/2017

1.1

6 of 61

5.2. OG5 PLANETARY VALIDATION FACILITIES ............................................................................... 51 5.2.1. DESCRIPTION ................................................................................................................................. 51 5.2.2. FUNCTIONAL INTERFACES ............................................................................................................... 51 5.2.3. HW INTERFACES ............................................................................................................................. 51

5.2.3.1. Power interfaces ................................................................................................. 51 5.2.3.2. Mechanical interfaces ........................................................................................... 51

5.2.4. DATA INTERFACES .......................................................................................................................... 52 5.2.5. TEST INPUTS/OUTPUTS ................................................................................................................... 53

5.2.5.1. Inputs................................................................................................................ 53 5.2.5.2. Outputs ............................................................................................................. 53

6. AIRBUS FACILITIES ......................................................................................................................... 54

6.1. OG1 PLANETARY VALIDATION FACILITIES ............................................................................... 54 6.1.1. HIGH LEVEL DESIGN (DESCRIPTION) ............................................................................................... 54 6.1.2. HW INTERFACES ............................................................................................................................. 55

6.1.2.1. Power/electrical Interface ..................................................................................... 55 6.1.2.2. Mechanical Interfaces - Accommodation of the OBC ................................................. 55

6.1.3. DATA INTERFACE ............................................................................................................................ 56 6.1.3.1. Locomotion Platform ............................................................................................ 56 6.1.3.2. Camera System .................................................................................................. 56 6.1.3.3. CAN Node .......................................................................................................... 56

6.1.4. TEST INPUTS/OUTPUTS PARAMETERS .............................................................................................. 56 6.1.4.1. Inputs................................................................................................................ 56 6.1.4.2. Outputs ............................................................................................................. 57

6.2. OG4 PLANETARY VALIDATION FACILITIES ............................................................................... 57 6.2.1. HIGH LEVEL DESIGN (DESCRIPTION) ............................................................................................... 57 6.2.2. HW INTERFACES ............................................................................................................................. 58

6.2.2.1. Power/electrical Interface ..................................................................................... 58 6.2.2.2. Mechanical Interfaces - Accommodation of the OBC ................................................. 58

6.2.3. DATA INTERFACE ............................................................................................................................ 58 6.2.4. TEST INPUTS/OUTPUTS PARAMETERS .............................................................................................. 58

6.2.4.1. Inputs................................................................................................................ 58 6.2.4.2. Outputs ............................................................................................................. 58

7. CONCLUSIONS ............................................................................................................................... 60

Code:

Date:

Version:

Page:



19/10/2017

1.1

7 of 61

LIST OF TABLES AND FIGURES

Table 1-1 Acronyms .................................................................................................................. 8

Table 2-1 Applicable Documents............................................................................................... 10

Table 2-2 Applicable Documents............................................................................................... 10

Table 3-1 Connections of the HW interfaces ............................................................................... 14

Table 3-2 Data interfaces ........................................................................................................ 15

Table 4-1 Handheld Central Rover Unit ..................................................................................... 30

Table 4-2 ExoMars BB2 frame dimensions ................................................................................. 32

Figure 3-1: OG1 Orbital – Elements to be made available by OG6 ................................................ 11

Figure 3-2: OG1 Orbital – Elements that will be tested from OG1 ................................................. 12

Figure 3-3: OG2 Orbital - Proposed Test Setup .......................................................................... 18

Figure 3-4: OG2 Orbital – Elements to be made available by OG6 ................................................ 19

Figure 3-5: OG4 Orbital – proposed test setup ........................................................................... 23

Figure 3-6: OG4 Orbital – Sensor suite boxes mounting .............................................................. 24

Figure 3-7: OG4 Orbital –board that will host the sensor suite boxes A and B on the flange of the facility’s KUKA robotic arm ................................................................................................. 24

Figure 3-8: KUKA KR 150-2 Flange technical draw ...................................................................... 25

Figure 3-9: Technical draw of retroreflectors monument.............................................................. 25

Figure 4-1: Pan-Tilt & perception (APU) mock-up (left) and LRU rover with perception unit (right) ... 29

Figure 4-2: Handheld Central Rover Unit ................................................................................... 30

Figure 4-3: ExoMars Phase B2 breadboard refurbished design with outer and inner (left) frame ....... 31

Figure 4-4: Light Weight Robot mounted on the chaser satellite mock-up of the OOS-SIM facility. Also visible are the stereo camera system at the end-effector, the potential position of a LIDAR system and the target satellite mock-up (on the left). ...................................................................... 34

Figure 4-5: OG5 testing at OG6 facilities: architecture ................................................................ 37

Figure 4-6: Communication Architecture for OG5-OG6 (orbital) .................................................... 38

Figure 4-7: The weight of the cables sustained by the Robotic Arm. When the payload (blue) is removed, the cables (black) does not fall down. This implies that the cables themselves are sustained by the glued fixtures and Velcro stripes. ................................................................ 40

Figure 4-8 Output Flange of DLR Light-Weight Robot with bolt pattern .......................................... 42

Figure 5-1: SHERPA_TT rover .................................................................................................. 45

Figure 5-2: SHERPA_TT construction drawing & definition of x-y-plane ......................................... 46

Figure 5-3: SHERPA control structure ....................................................................................... 46

Figure 5-4: SHERPA electronics overview (simplified) .................................................................. 47

Figure 5: SHERPA teleclient C++ .............................................................................................. 48

Figure 6: Methods of SherpaTTTeleClient and its data types ........................................................ 48

Figure 5-7: SHERPA manipulator dimensions ............................................................................. 51

Figure 5-8: Manipulator arm flange for mounting an end-effector to the tip of the robotic arm ......... 52

Figure 5-9: SHERPA main frame with mounted manipulator and slots for APMs (blue)..................... 52

Figure 6-1: OG1 Planetary - Bridget rover Testbed platform supporting OG1 tests .......................... 54

Figure 6-2: OG1 Planetary - Validation Scenario Setup at Airbus DS ............................................. 55

Figure 6-3: OG4 Planetary – OG4 Test Area at Airbus DS ............................................................ 57

Figure 6-4: Mars Yard Frame definition - Shaded area denote sloped banks ................................... 59

Code:

Date:

Version:

Page:



19/10/2017

1.1

8 of 61

1. INTRODUCTION

1.1. PURPOSE

This document is the deliverable 2.1 of the H2020 FACILITATORS project, and it contains the identification and description of the interfaces of the facilities that will be available to the other OGs for their validation campaign.

The interfaces to the test facilities that have been identified so far have to be understood as preliminary and will be further detailed in the course of the project until the Test Readiness Review. It is therefore expected that this document will have further updated issue.

1.2. SCOPE

This document is the technical note deliverable D2.1 in the frame of the WP2000 of the FACILITATORS project.

1.3. DISSEMINATION LEVEL OF THIS DOCUMENT

This document is to be considered as Public.

1.4. ACRONYMS

Acronyms used in this document and needing a definition are included in the following table:

Table 1-1 Acronyms

Acronym Definition

ADS Airbus Defence and Space

BLS Bridget Locomotion Software

BRMC Bridget Remote Monitor and Controller

CAN Controller Area Network

COTS Commercial Off the Shelf

CPU Central Processing Unit

DoF Degree of Freedom

DSM Digital Surface Model

FPGA Field programmable gate array

FPS Frame per second

GEO Geosynchronous orbit

GNC Guidance Navigation and Control

GPS Global Positioning System

GUI Graphical User Interface

HDL Hardware description language

HIL Hardware in the loop

IBDM International Berthing and Docking Mechanism

ICD Interface Control Document

IMU Inertial Measurement Unit

IOD In Orbit Demonstration

IOV In Orbit Validation

ISS International Space Station

LAN Local Area Network

LEO Low Earth Orbit

LRO Lunar Reconnaissance Orbiter

LWR Light Weight Robot

MEMS Microelectromechanical systems

Code:

Date:

Version:

Page:



19/10/2017

1.1

9 of 61

Acronym Definition

MIL Model in the Loop

MSR Mars Sample Return

NEO Near Earth Object

OOS On Orbit Servicing

PEL Planetary Exploration Lab

PHY Physical layer

PTU Pan and tilt unit

RAM Ra

RTOS Real Time Operating System

TBC To be confirmed

TBD To be defined

TCP Transmission Control Protocol

TOF Time of Flight

TRL Technology Readiness Level

TRP Technology Research Program

UART universal asynchronous receiver/transmitter

UDP User Datagram Protocol

VBS Vision Based System

VPN Virtual Private Network

WIFI Wireless network

Code:

Date:

Version:

Page:



19/10/2017

1.1

10 of 61

2. REFERENCES

2.1. APPLICABLE DOCUMENTS

The following documents, of the exact issue shown, form part of this document to the extent specified herein. Applicable documents are those referenced in the Contract or approved by the Approval Authority. They are referenced in this document in the form [AD.X]:

Table 2-1 Applicable Documents

Ref. Title Code Version Date

[AD.1] Grant Agreement number 730068 – FACILITATORS, between the

Research Executive Agency and GMV Aerospace and Defence

Ares(2016)6010193 1.0 19/10/2016

[AD.2] FACILITATORS CATALOGUE GMV-FACILITATORS-D1.1

1.1 21/02/2017

[AD.3] FACILITATORS SYSTEM REQUIREMENTS DOCUMENT H2020.OG6.ADS.D1.2 2.0 24/02/2017

[AD.4] FACILITATORS PRELIMINARY DESIGN DOCUMENT H2020 OG6 -

FACILITATOR_D2.2

1.0 23/06/2017

[AD.5] D2.6.1 OG4 VALIDATION PLAN AT OG6 FACILITIES O4-D2.6.1 1.0 10/08/2017

2.2. REFERENCE DOCUMENTS

The following documents, of the exact issue shown, form part of this document to the extent specified herein. They are referenced in this document in the form [RD.X]:

Table 2-2 Applicable Documents

Ref. Title Code Version Date

[RD.1] Bridget Rover hardware and Software ICD ADS_ICD_BLS_001 1.2 14/04/2017

[RD.2] Airbus Mars Yard Ground Truth Position System ICD ADS_ICD_POS_001 1.0 17/04/2017

[RD.3] CAN Node Software ICD ADS_ICD_CAN_001 1.0 To be issued

[RD.4] Integrated OG1-OG6 ICD (from PERASPERA PSA) 1.0

[RD.5] UR5 user manual UR5/CB3 3.0 (rev 15965)

Code:

Date:

Version:

Page:



19/10/2017

1.1

11 of 61

3. GMV FACILITIES

3.1. OG1 ORBITAL VALIDATION FACILITIES

3.1.1. DESCRIPTION

OG6 will provide two different tests setups depending on quality of the ERSROCOS software to be validated:

laboratory quality test and

space quality test, which includes space representative avionics.

For the space quality tests, three computers will be prepared

A Control Centre on a Linux machine with ESROCOS tools

A Linux PC to run an application built with ESROCOS

A SPARC LEON computer running RTEMS and an application built with ESROCOS

For the laboratory quality tests, no SPARC LEON computer will be needed.

LINUX PC

SPARC LEON BOARD

LINUX PC

UR5 ROBOTIC ARM

ETHERNET CAMERA

UR5 CONTROLLER

SPACEWIRE MONITOR

ETHERCAT MONITOR

seria

l

seria

l

Ethernet

Ethernet

Ethernet

Ethernet

Ethernet

SpaceWire

EtherCat

CONTROL CENTER

ESROCOS SPACE QUALITY SW

ESROCOS LAB QUALITY SW

Figure 3-1: OG1 Orbital – Elements to be made available by OG6

Support tools will be deployed on the control center machine (Logging tools, 2D/3D data visualization tools), which will have GRMON/DMON is installed and connected to RTEMS board via serial link through a USB/serial adapter. The control centre will mimic a ground-to-space line using TCP/IP

sockets. Fault injection capabilities will be included in the control center.

Applications generated with ESROCOS will be executed on Control Centre. This application will use libraries that will add PUS Services and Time Stamp alignment functionalities.

Applications generated with ESROCOS will be executed on RTEMS board computer. This application will use libraries that will add PUS Services, Time Stamp alignment and instantaneous motion solver, these applications will control the platform of robotic arm by Ethernet.

Applications generated with ESROCOS will be executed on Linux PC. This applications will be able to support RTEMS board computer to add extra functionalities developed in lab quality. It will send data via serial link to OBC.

Code:

Date:

Version:

Page:



19/10/2017

1.1

12 of 61

Applications of laboratory quality will be executed in Control Centre PC or Linux PC while space quality applications will be executed on space RTEMS board. All tests can be configured as a subset of these tools or artefacts.

All computers will have fixed IP addresses, assigned for instance by a configurable router.

The UR5 robotic arm will be controlled from either the ESROCOS laboratory and space quality software via an Ethernet interface. Image acquisition will be enabled by providing a camera with Ethernet interface, connected to the ESROCOS laboratory quality OBSW.

In order to test the SpaceWire and EtherCAT space-quality drivers, OG6 will make available an EtherCat monitor and a SpaceWire monitor.

Figure 3-1 depicts the main element that will be provided by OG6, while Figure 3-2 depicts the

components of ESROCOS that will be deployed in the different units.

LINUX PC

APPLICATIONS

BINARIES.

(Lab quality)

RTEMS PC

EtherCAT Driver

Seria

l Bus

Ethernet

Ethernet

Ethernet

SpaceWire Driver

ROBOTIC ARM

PLATFORM CONTROLLER

CAMERA

TSP HYPERVISOR

HIGH INTEG RITY

MIDDLEWARE

HIGH INTEG RITY

MIDDLEWARE

EXTERNAL MIDDLEWARE

BRIDGES

APPLICATIONS

BINARIES.

(Space quality)

LIBRARIES

TimeStamped data alignement

PUS Services

Instantaneous motion solver

External libraries

Logging

CONTROL

CENTRE PC

2D/3D Data

Visualizations

SUPPORT TOOLS

ROS topics

ROCK C omponents

EXTERNAL ROBOTICS

TOOLS

LIBRARIES


PUS Services

APPLICATIONS

BINARIES.

(Lab quality)

Serial Bus

GRMON

Ethernet LIBRARIES


PUS Services

Instantaneous motion solver

Spacewire BusSPACEWIRE MONITOR

ETHERCAT MONITOR

Ethernet

Figure 3-2: OG1 Orbital – Elements that will be tested from OG1

Code:

Date:

Version:

Page:



19/10/2017

1.1

13 of 61

3.1.2. HW INTERFACES

3.1.2.1. On Board Computer

OG6 shall provide an on board computer to host ESROCOS.

For laboratory grade tests, a Linux x86 machine will be made available.

For space grade tests, a GR-RASTA development platform will be made available with a LEON board, the GR-740 has been selected in agreement with OG1.

3.1.2.2. Camera

OG6 will provide a TBD camera with an Ethernet interface.

3.1.2.3. Robotic arm

OG6 will provide a UR5 robotic arm to be commanded via Ethernet following [RD 3].

The UR-5 robotic arm can achieve up to 0.1 mm of repeatability performance.

3.1.2.4. Monitors

The Spacewire brick (https://www.star-dundee.com/products/spacewire-usb-brick-mk3) will read the

packets sent and will be used to build a test application.

Similarly, an EtherCAT monitor TBD will do the same by monitoring Ethernet messages using

Wireshark running on Linux.

3.1.2.5. Connections

The following table depicts the connections between the different elements under test as identified in Figure 3-2.

HW component

Interface Description and purpose Type Remarks

Ethernet Bus

Ethernet cable Physical cables RJ45 that will be

connected to communicate Control centre PC, Linux PC, Ethernet camera and UR5 controller to a common Router

IP.

Transmission line

The logical

communications will be though TCP/IP sockets over Ethernet

Router IP Device that will route IP traffic in a IP local network

Device All Ethernet communications

will be deployed over a local IP network supported by GMV.

SpaceWire Bus

SpaceWire cable Physical cable SpaceWire that will

be connected between RTEMS board and the SpaceWire brick

Transmission line

All connections

will be PnP. Only it is necessary one Spacewire connection so

Spacewire router

will not be necessary.

Code:

Date:

Version:

Page:



19/10/2017

1.1

14 of 61

HW component

Interface Description and purpose Type Remarks

Adapter SpaceWire-USB

Adapter that will send and receive SpaceWire data traffic by USB

Device It is necessary to

interpreter traffic from an application that applies a SpaceWire monitor.

EtherCAT bus

EtherCAT cable Physical cable RJ45 with quality EtherCAT that will be connected

between RTEMS board and an

Ethernet connector of a Linux computer with Wireshark that will monitor traffic EtherCAT

Transmission line

This cable will connect to a slave

device (RTEMS

board) and a master device (Ethercat monitor software in a computer)

Serial Bus

Serial cables Physical cables that will connect

RTEMS board with Control Centre PC and Linux PC

Transmission line

Adapter serial bus-USB

Adapters that will send and

receive serial data traffic by USB port.

It is necessary

since some computers lack the needed

number of COM ports.

Table 3-1 Connections of the HW interfaces

3.1.3. DATA INTERFACES

The following table depicts the different software elements that will be made available by OG6.

SW component

Description and purpose Type Version Remarks

Linux Operating System that will be

used to run applications of laboratory quality.

OS Ubuntu 14.04 This version is TBC.

RTEMS

Operating System of real time

that will be used to run applications of space quality.

OS RTEMS 4.10 This version is TBC

ROCK

Framework of robotics. It is

based on the Orocos RTT (a real time toolkit). It provides a wide variety of robotic components defined by output ports, input ports and tasks.

Framework Updated version

from https://github.com/rock-core/rock-package_set

ROS

Framework of robotics that

implements a wide variety of intelligent algorithms related to robotics. It provides a variety of ROS topics that are able to send messages to other applications.

Framework Indigo

Code:

Date:

Version:

Page:



19/10/2017

1.1

15 of 61

SW component

Description and purpose Type Version Remarks

EtherCAT monitor

EtherCAT monitor is a specific

software (Wireshark TBC) that it is able to read and interpreter EtherCAT data traffic implementing master protocol.

Application Wireshark 2.2.7 (TBC)

It is not necessary

a specific EtherCAT hardware being possible to use a common Ethernet

interface if it adopts a master role.

SpaceWire monitor

SpaceWire monitor is a specific

software (Star system and associated tools) that it is able to read and interpreter SpaceWire data traffic though an USB connection. The SW is connected to the SpaceWire Brick Mk3

Application Star-System 2.0

DMON

Application that will be is used with SPARC LEON board to

monitor hardware, debug software and analyse dynamically activities though serial ports.

Application 2.0.11.5 It is also possible to use DMON

trough Ethernet connection.

URScript

UR controller can execute

URscipts to program using simple instructions like movej (move in joint space), movel (move linear in Cartesian space), speedj(velocity joints)

and others more complex like tracking, sockets and Modbus communication, threading and force/torque based control.

Script file URScript is based

on Python language. It permits to command UR controller at 125 Hz.

Robot state interfaces

The firmware of UR controller

provides information about robot state information on ports 30001 and 30002, like joint position, voltages and

temperatures across the

system, IO status, TCP force, Cartesian position

Messages

sent by TCP/I sockets.

It is not

recommended to use these interfaces in a deterministic manner.

Real time interfaces

On port 30003 the firmware publishes information a. is found at port 30003. It publishes not faster than 125 Hz information about actual and target joint position and joint

speed, as well as actual joint moment, joint current and joint temperature.

Messages

sent by TCP/I sockets.

These interfaces

will be chosen to command the robot by ESROCOS.

Dashboard

server

The port 29999 is used to load and run programs.

Messages

sent by

TCP/I sockets.

In principle. This

interface will not be used.

Table 3-2 Data interfaces

Code:

Date:

Version:

Page:



19/10/2017

1.1

16 of 61

3.1.4. TEST INPUTS/OUTPUTS

3.1.4.1. Inputs

The following will be the test inputs:

Joint positions of the UR5 commanded by ESROCOS

Command by ESROCOS to take picture

Standard messages to be checked by Spacewire brick and EtherCAT monitor

3.1.4.2. Outputs

The outputs of the test will be:

Pictures taken by the camera

trajectory attained by UR5 robot in terms of joint movements

packet analysis of messages received by the Spacewire brick and the EtherCAT monitor

3.1.4.3. Parameters

None identified at this stage.

Code:

Date:

Version:

Page:



19/10/2017

1.1

17 of 61


3.2.1. DESCRIPTION

The objective of OG2 validation in the orbital track are to:

Demonstrate reactivity to scenario modifications

Re-planning based on updated information

The reference mission for the orbital track is the On-Orbit Servicing mission of a modular spacecraft, where a damaged spacecraft can have one of its modules replaced autonomously by a servicer spacecraft. The objective of this orbital scenario is the evaluation of the autonomy performance of the

controller in a “robot agent” type scenario. It implies that the architecture and test environment must allow:

Demonstrating reactivity to scenario modifications caused by two different sources: 1) Failures such as pieces or tools not present in the expected place or found in a different attitude,

obstacles in the visual field, changes in the illumination constraints, failure in grasping pieces etc...); 2) Deviations with respect to the nominal mission, such as reconfiguration of the spacecraft due to mission constraints

Re-planning based on updated information from the environment. For that purpose, feedback information needs to be obtained by the available sensors.

Generation of high level information with re-plan decisions and lower level schedules for

downlink to ground with supervision when possible.

This complex scenario is proposed to be adapted to the demonstration need on an orbital facility requiring several items such:

Manipulator Robotic arm mounted on the top of a ground laboratory robotic arm (emulating

ingravity conditions) simulating the chaser spacecraft. The emulation of the ingravity conditions could consider that the chaser S/C is in station keeping mode separated by ~1m (within the reach of the robotic arm) of the target S/C with some perturbations affecting its

center of mass.

Additionally it could be considered that on the base of the robotic arm there is a flat mounting panel simulating the front side of the chaser S/C and hosting one or two modular cubes emulating the reconfigurable spacecraft modules (the APM). These cubes should have means to be grasped and to get attached to the client spacecraft.

Satellite mock-up mounted on the top of a second ground laboratory robotic arm (considered to be fixed in a set of predefined positions/orientations; the emulation of its ingravity

conditions would be performed directly by combining the motions of both the two ground laboratory robotic arms). Additionally it might be needed a solar array or similar element obstructing the nominal path of the robotic arm.

This satellite mock-up should have one or two APMs emulating the reconfigurable pieces of the

spacecraft.

Perception means (such as a visual navigation camera) and emulated grasping means (e.g.

magnet to grasp the modular satellite box) on the tip of the manipulator robotic arm

Visual markers on the client and on the APMs to assist visual navigation

Emulation of space illumination conditions through a lamp-based Sun emulator system (in case that stereo-cameras are used as perception means)

On-board computer hosting a Linux x86 64-bit operating system.

The facility shall provide a module that will control the robotic arm, electro-magnet (or any means of grasping APMs) and compute visual navigation to deliver to ERGO the positions of

the APMs

Therefore, it is proposed that the scenario will be reproduced at GMV’s platform-art with:

2 robots, one mounting the client and another with a third robotic arm acting as manipulator

A number of Active payload module (APM) mock-ups, which have means to be attached to the client and to be grasped by the manipulator

Code:

Date:

Version:

Page:



19/10/2017

1.1

18 of 61

The client gets replaced a defect APM (active payload module) with a new one from the servicing robotic arm

Camera on tip of manipulator and visual aids placed on the APM mock-ups

Orbital conditions (dynamic, illumination)

Fault injection (position of solar array different to what expected…)

OG2 controllingmanipulator with APMs

Figure 3-3: OG2 Orbital - Proposed Test Setup

The scenario will be implemented in two incremental steps in order to enable gradual testing of ERGO:

First, a flat mock-up mounted on the second KUKA arm

Then a full 3d satellite mock-up mounted on the second KUKA arm

The following elements will be made available by OG6 (refer to Figure 3-4 for captions):

A. grasping means (such as magnets or electromagnets)

B. APM mock-ups. These mock-ups also include markers for visual navigation

C. UR5 manipulator

D. UR5 controller

E. board for mounting on KUKA flange, acting also as servicer tray

F. Visual navigation module, connected to a camera mounted on the tip of the UR5 manipulator. This module provides the pose (position and orientation of the UR5 with respect to the mock-up of the client and the various APMs

G. Linux PC with arm motion planner, commanded by ERGO system

H. Mock-up of client spacecraft, with markers to aid visual navigation and other elements (such as solar array..)

I. GNC module of the orbital scenario, commanded by the ERGO system, in charge of the relative motion of the client with respect to the servicer

A separate Linux machine will host the ERGO system.

Code:

Date:

Version:

Page:



19/10/2017

1.1

19 of 61

UR5 controller

ERGOFacilityMotionSystem

A A

dSpace

B

D

A

AA

C

Ethernet UDP/IP joint commands to KUKA 1

Ethernet TCP/IPUR5 commands H

B

A

AA

A

GNC

pose

Ethernet UDP/IP joint commands to KUKA 2

Commands to GNC

Time synch

UR5 jointcommands

E

F

G

I

Visual navigation

Arm motionplanner

Figure 3-4: OG2 Orbital – Elements to be made available by OG6


3.2.2.1. Power interfaces

A standard power supply will be made available for the ERGO Linux machine.

3.2.2.2. Data connection

The ERGO machine will be connected to:

The arm motion planner machine, via Ethernet

The dSpace machine (which includes the GNC) via Ethernet

The visual navigation machine, via Ethernet

3.2.3. SW INTERFACES

3.2.3.1. Visual navigation link

ERGO will receive from the visual navigation machine the position of the APMs (on the mock-up and on the tray) and of the mock-up. This will enable ERGO to create a map of the environment and hence plan the movements of the APMs.

3.2.3.2. Arm motion planner link

ERGO will have an interface to arm motion planner machine via Ethernet through an API. The arm motion planner machine will host ROS with MoveIT! (TBC), directly connected to the UR5 controller.

Through this API, ERGO will send command to:

A - Evaluate the possibility of picking an APM and placing it in a defined spot

B - Command the movement of picking an APM and placing it in a defined spot

Code:

Date:

Version:

Page:



19/10/2017

1.1

20 of 61

ERGO will receive from the UR5 motion planner the following information:

Confirmation that the A command is feasible and it associated cost (in terms of time or number of joint movements) or elsewise

Confirmation that the B command has been successfully carried out or elsewise

This API will be provided by OG6.

OG6 will provide to ERGO a behavioural model of the arm motion planner (TBC).

3.2.3.3. GNC link

The GNC is in charge of reproducing the relative orbital dynamics between the client spacecraft and the chaser, which has a manipulator (the UR5). The GNC is hosted in the dSpace machine.

ERGO will send commands to the GNC through an API. This will enable to send commands to modify the orientation of the chaser with respect to the client, in order to be in reach of a different face of the satellite. The GNC will send confirmation that the new orientation of the chaser has been carried out

or elsewise.

This API will be provided by OG6.

OG6 will provide to ERGO a behavioural model of the GNC (TBC).

Note that the planning of the robotic arm motion is done within ERGO system.

3.2.3.4. Synchronisation link

The synchronization link between ERGO and OG6 is used to send a synchronisation packet to the ERGO in order to synchronise the system with the facility.

This interface is implemented over an Ethernet link between the facility Motion Control System and

the ERGO machine.

The synchronization packet is sent at a constant time period of 120ms.

The content of the UDP/IP packet, embedded in the UPD frames is detailed below:

Time tag of the Motion Control Facility

Data format (Endian, type) is TBD


3.2.4.1. Inputs

The following will be the inputs to ERGO:

Position and orientation of client mock-up

Position and orientation of the APMs (both on the client and on the servicer tray)

The data shall be obtained with the optitrack system (with beacons) from the platform-art

3.2.4.2. Outputs

The following will be the outputs of the test that will be delivered to ERGO:

Position and orientation of client mock-up during the test

Position and orientation of the servicer (and the tip of the robotic arm) during the test

Position and orientation of the APMs (both on the client and on the servicer tray) during the test, in order to compute the configuration of the APMs

3.2.4.3. Parameters

The following parameters will be setup before or during each test:

APMs configuration (position, operational status) on the mock-up and on the servicer tray (in order to modify during the test the position of one APM with respect to the map that has been used to generate the planning)

Code:

Date:

Version:

Page:



19/10/2017

1.1

21 of 61

Other failures that can be injected in the scenario (position of obstacles on the mock-up…) that can test the replanning capabilities of OG2

Code:

Date:

Version:

Page:



19/10/2017

1.1

22 of 61


3.3.1. HIGH LEVEL DESIGN

The objective of the OG4 I3DS project is to realize a state of the art Inspection Sensors Suite (ÏNSES) constituting the basic bricks for enabling advanced perception and navigation functionalities for both planetary and orbital scenarios.

For the orbital scenario, the sensors detailed in Table 2 of [AD.5] have been selected:

LIDAR

Visible Stereo camera

Wide illumination

HR camera

Pattern projection

Other sensors are part of the I3DS sensor suite built for orbital tests, but given that the facility is not

able to provide a proper stimulus/environment, the measurements provided will not be representative of space conditions and therefore they are only tested at interface level.

Star tracker (not stimulated by relevant environment)

HF Radar (not stimulated by relevant environment)

Tactile Sensor (not stimulated by relevant environment)

F/T Sensor (not stimulated by relevant environment)

The INSES will include redundancy of the sensor(s) and reconfigurability capabilities. Some ancillary equipment will be developed and integrated as part of the sensor system and has to be considered as further output of the OG4, such as an illumination system, the inclusion of retroreflectors and optical markers. The sensors suite from OG4 will include redundancy and will be based on modularity and plug-in concept enabling its re-configurability. The INSES will have standardized interface for

communicating with other OGs elements

The validation/testing activities to be conducted within OG4, using the facilities, assets and support from FACILITATORS, will have as target the two reference implementations of INSES for the two reference scenarios (orbital scenario and planetary scenario). In each scenario, OG6 facilities shall verify that the sensor suite is re-configurable and satisfy the modularity / plug-in concept.

The objective of OG4 validation in the orbital track are to:

Verify that the sensor suite is re-configurable and satisfy the modularity / plug-in concept.

Verify that the sensor suite provides measurements as expected.

Verify the sensor suite compatibility and its various interfaces (power, electrical, data, thermal): functional test only

This test consists in functional validation only. OG4 expects OG6 to reproduce the dynamics & test conditions to fit the scenarios of OG4 before the colocation, since the reproduction of dynamics would have already been tested within OG4. Please note that during the testing campaign the sensors can be added/removed in the suite only before the experiment.

The scenario that will be reproduced is the orbital rendez-vous (up to few centimetres, avoiding contact) between two satellites. Therefore, Tactile sensors and Force and Torque sensors will not be tested.

Similarly, given the characteristic of the facility, radar, and star tracker will not be tested functionally.

Scenario will be reproduced at platform-art with 2 robots, one mounting a mock-up of the client and another on a rail with the full sensor suite placed on the tip (see Figure 3-5). Illumination source will

also be provided by OG6. This test will stimulate most of the sensors included in the suite: it will not

be possible however to stimulate correctly the radar, the IMU and the star tracker. As the preliminary estimated weight of the sensor suite is below 20kg, this is considered to be well within capabilities of the platform-art robotic arm (100kg of payload capability).

A synchronisation mechanism will be sent from the facility real time motion system to the sensor suite. The readings of the sensor suite will be retrieved by OG4.

Code:

Date:

Version:

Page:



19/10/2017

1.1

23 of 61

Figure 3-5: OG4 Orbital – proposed test setup

Discussions with OG4 have identified that the sensor suite will be composed by the following elements

(see figures below for references from A to F)

Two boxes with sensors (A and B)

An Instrument Control unit (C)

For the test, OG4 will provide a data acquisition system (D)

Elements A and B will be mounted on a board (E) using the same mechanical interface provided by

OG4 and used in the OG4 robotic facility (see [AD.5] sections 1.2 and 1.3).

The board E will also include fixtures for installing retroreflectors F. The board will be compatible (on

its bottom side) with the mounting fixtures of the KUKA robotic arm flange. The fixtures will be

precisely manufactured, with precision below the mm, in order to be compatible with the calibration

objectives.

Elements C and D will be mounted on the moving platform at the bottom of the KUKA robotic arm.

The real time motion system of the facility, which moves the KUKA arm (as well as the mock-up), will

be connected to the acquisition unit D in order to send a synchronisation pulse via Ethernet link

(UDP/IP).

Code:

Date:

Version:

Page:



19/10/2017

1.1

24 of 61

Figure 3-6: OG4 Orbital – Sensor suite boxes mounting


3.3.2.1. Power/electrical Interface

The access to AC 220V unregulated power is provided by OG6 through the use of CEE 7/3 (Schuko) socket(s) which can be installed on the flange of the robotic arm, or on the moving platform on which the robotic arm is installed.

3.3.2.2. Mechanical Interfaces

3.3.2.2.1. Mounting of I3DS sensors suite box

The proposed mounting solution for OG4 sensor boxes A and B is to procure a board (named E in Figure 3-6) that will be mounted directly to the flange of the robot by using the 6 screwed 10mm metrics holes (see Figure 3-8). The board shall have a set of holes compatible with these mounting holes.

E

Precise mounting fixtures

E – top view

Precise mounting on KUKA flange

E – bottom view

Figure 3-7: OG4 Orbital –board that will host the sensor suite boxes A and B on the flange of the facility’s KUKA robotic arm

The OG4 mechanical interface board used for hosting boxes A and B in OG4 robotic facility will be mounted on this board following fixtures to be defined in accordance with OG4.

OG4 shall deliver technical draws of the I3DS OG4 mechanical interface board including precise measurements of the position of such sets of holes, expressed in the I3DS boxes reference frame; this

information is needed for the calibration of the installation of the I3DS boxes in the facility.

The board will include precise fixtures compatible with the KUKA flange (see figure below).

Code:

Date:

Version:

Page:



19/10/2017

1.1

25 of 61

Figure 3-8: KUKA KR 150-2 Flange technical draw

Boxes C (ICU) and D (acquisition unit) will be mounted at the base of the KUKA robot and will be connected to the motion control system.

3.3.2.2.2. Interface for Facility Calibration Retroreflectors

The facility calibration is based on a laser tracker system which uses retroreflectors. For proper calibration it is needed that the board E that will be prepared will have 4 sets of holes for retroreflectors mounting.

Each set of holes shall be compatible with the holes of the retroreflector monument depicted in Figure 3-9.

Figure 3-9: Technical draw of retroreflectors monument

The 4 sets of holes shall be placed at the 4 angles of the mounting board.

Code:

Date:

Version:

Page:



19/10/2017

1.1

26 of 61

3.3.2.3. Mock-up interfaces

The mock-up manufactured by OG6 will have the following elements:

Monuments for retroreflectors (see Figure 3-9): placed at 4 angles of the mockup

Visual aids / markers: placed in TBD position. COTs markers chosen by OG4 will be used, OG4 will specify the position for their installation.

3.3.2.4. Synchronization link

The synchronization link between OG4 and OG6 is used to send a synchronisation packet to the I3DS in order to synchronise measurements logs with the realised trajectory.

This interface is implemented over an Ethernet link between the facility Motion Control System and

the OG4 I3DS acquisition system.

This interface is based on UDP/IP packets sent by the Motion Control System, whose content is detailed in 3.3.3.1.

3.3.3. DATA INTERFACE

3.3.3.1. Synchronization link packet

The synchronization packet is sent at a constant time period of 120ms.

The content of the UDP/IP packet, embedded in the UPD frames is detailed below:

Time tag of the Motion Control Facility

Data format (Endian, type) is TBD

3.3.4. TEST INPUTS/OUTPUTS PARAMETERS

3.3.4.1.1. Inputs

The input needed by OG6 (or produced by OG6 in agreement with OG4) is the definition of trajectories to be realised.

Please notice that the target satellite mock-up Geometric Reference Frame origin will be left steady.

The following data defines the scenario trajectories:

Time tag

Sensors Suite Position (of the origin of the I3DS reference frame) expressed in target mock-up Geometric Fixed frame

Sensors Suite Attitude (of the I3DS reference frame) expressed in target mock-up Geometric Fixed frame at t=0

Target Mock-up Attitude expressed in target mock-up Geometric Fixed frame at t=0

Illumination system Orientation (Elevation and Azimuth angles) expressed in target mock-up

Geometric Fixed frame at t=0

These data will be written in a text file or Matlab (.mat) file.

3.3.4.1.2. Outputs

The test output provided by OG6 to OG4 is the realised trajectory computed by the robots telemetry (which may slightly differ from the commanded ones) after calibration offset. Note that this will enable to calculate the position and orientation of the sensor boxes A and B during the test.

The internal calibration of the sensor within the boxes A and B will be carried out by OG4.

The same data defined in 3.3.4.1.1 are given as output of the test executed in the facility from OG6 to

OG4.

These data will be written in a text file or Matlab (.mat) file.

Environmental data of each test:

Room temperature

Luminous flux on the mockup

Code:

Date:

Version:

Page:



19/10/2017

1.1

27 of 61

Light Source Spectrum (taken from the data-sheet of the light source)

3.3.4.1.3. Parameters

The parameters that will be provided by OG6 to OG4 are the following:

3D technical draw of mock-up including position of visual markers.

Code:

Date:

Version:

Page:



19/10/2017

1.1

28 of 61

4. DLR FACILITIES

4.1. OG3 PLANETARY VALIDATION FACILITIES

4.1.1. HIGH LEVEL DESIGN (DESCRIPTION)

The objective of the OG3 InFuse project is to realize a state of the art Common Data Fusion Framework (CDFF) constituting the basic bricks for enabling advanced perception and navigation functionalities for both planetary and orbital scenarios. InFuse aims to develop a comprehensive data

fusion toolset for robot sensors that will serve in the context of many space robotics applications, on planetary surface as well as in orbit or other space environments. The OG3 CDFF will be developed for

a wide range of sensor data handling and processing techniques (Perception and Navigation related) and a wide range of robotic applications – both in space and terrestrial conditions. The solution proposed in InFuse to wrap and handle data fusion techniques and their produced data will make their adoption easy and effective by a wide range of users.

The validation and testing activities foreseen by FACILITATORS to support these OG3 activities

includes a planetary reference implementation. A corresponding reference scenario or set of scenarios is assumed that shall cover all major and relevant aspects of the underlying space application to the maximum extent. In each scenario, OG6 facilities shall verify that the CDFF allows merging, combining and finally processing the relevant sensor data. For the planetary track, or a long range Martian scientific mission is assumed that will allow future Martian rovers to roam across the vast extents of the Martian surface and return autonomously detected science, compatible with the limited energy and telecommunication budgets associated to Martian missions. In order to support such a scenario,

the resulting objectives of OG3 in the planetary track are:

Localizing its pose and objects

Building a map of the environment´

Evaluating the rover or reference system state for quality analyses of the fusion

The underlying overall reference application is therefore mapped on a set of scenarios and test

sequences to cover all major aspects. Typically such planetary missions have to deal with two major

challenges:

1. Travelling large distances between two or more interesting sites in relatively easy and

moderate terrain and/or avoiding critical regions and obstacles

2. Performing complex tasks e.g. at scientifically interesting but more challenging sites requiring

higher accuracy

It has been therefore commonly agreed that a combination of a long range scenario and a more precise short range scenario fits the needs of OG3 planetary validation and testing best. The

overall validation strategy has to be finally agreed by OG3 and OG6 and strongly depends on the approach and selection of the field trials e.g. in Morocco. Next, planetary exploration typically has to deal with very limited resources and tight mass, volume and power budgets. Therefore it is desirable to rely mainly on standard sensor data and it can be assumed that a future planetary rover will provide basic wheel odometry and will be equipped - as a minimum - with cameras and IMU. Therefore the standard DLR perception unit will be considered as the baseline InFuse planetary sensor suite as it is equipped with IMU, stereo cameras and color camera. This

perception unit is available as a stand-alone handheld device or can be integrated/mounted on the DLR ExoMars or LRU rover. For the field trials, the HCRU could also be mounted on the DFKI SherpaTT rover (TBC) with corresponging data syncronisation (e.g. trigger). In addition, the HCRU/ExoMars BB2 shall allow to integrate the following OG3 provided sensors:

Pan-Tilt-Unit

IMU - complementary single axis high precision fibre optic gyro (provided by LAAS-CNRS, KVH

5000)

2nd Stereo camera (Visual odometry + hazard cam)

3D lidar (e.g. multi-beam/channels)

Code:

Date:

Version:

Page:



19/10/2017

1.1

29 of 61

It shall be mentioned that to simulate a sensor setup similar to the one from OG4, the following optional sensors would have to be considered in the final validation setup:

ToF camera (Not availalbe, but couldn be procured by OG3)

Thermal IR cam (DLR, TBC)

High resolution monochromatic cam - Not available

Depth maps from pattern projection (similar to Kinect) - Not available

These optional sensors are neither foreseen nor required and at the time being are therefore not considered as baseline and any future implementation has to be based on their

availability/procurement within OG3 and OG6.

The stand-alone unit represents an independent rover mock-up which is fully representative in terms of software and hardware architecture but does not provide any active mobility elements like wheels. Nevertheless, it allows e.g. testing rover elements and payload or sensor integration. The stand-alone but fully representative mock-up will be provided by OG6 to OG3 (TBC with OG3). This unit allows generating representative data sets and therefore testing and validating the CDFF. As this approach allows using the device as build, the only interface for this application is the output data (e.g. type, format).

For the second part, testing on rover level, this mock-up will then be mounted on the ExoMars rover ‘as tested’ (including all additional and optional OG3 provided sensors). The DLR standard internal connection between rover and mock-up can be used and no contribution of OG3 is required. For the second part, the only additional interface (except adding rover proprioceptive sensor data to output) the rover hosted mock-up is given by feeding in the desired rover trajectory. The ExoMars rover shall be manually controlled via a gamepad or with a predefined path (e.g. very near waypoints).

Optionally, the manually generated trajectory can be stored e.g. by means of waypoints. This allows teaching and step by step optimization of the final desired test trajectory and the test can be repeated or reproduced.

Figure 4-1: Pan-Tilt & perception (APU) mock-up (left) and LRU rover with perception unit (right)

Core element is the Handheld Central Rover Unit HCRU which is an identical copy of both, the LRU and

ExoMars BB2 rover core software and hardware elements. It can be equipped with optional rover modules to set up specific mock-up scenarios and configurations e.g. the Perception Module or the

Jaco 2 robotic arm.

In fact, the Handheld Central Rover Unit HCRU itself defines or even forms the key interface between OG3 and FACILITATORS. It allows testing, implementing and even validating typical rover features

Code:

Date:

Version:

Page:



19/10/2017

1.1

30 of 61

and components independent from the rover and the HCRU itself can be easily connected to the rovers (default, two communicating OBCs) or be replaced by the rover OBC (optional). This approach maximizes usability and flexibility and allows easily switching between the systems.

If required, optional OG3 provided sensors and hardware can be added and integrated with the HCRU (TBC WITH OG3) and therefore also validated. Currently no optional sensors are foreseen. To support integration of potential future OG3 provided components, corresponding candidate major interfaces are also briefly addressed within this document and have to be refined on a case to case basis.

Figure 4-2: Handheld Central Rover Unit

Within the FACILITATORS activities a second HCRU tailored to the needs of OG3 will be set up.

Candidate modifications are the aluminium frame (mechanical interface) or connectors. The current

reference HCRU depicted in Figure 4-2 is therefore only for guidance and the overall dimensions and

mass of the reference unit are summarized below in Table 4-1.

Table 4-1 Handheld Central Rover Unit

HCRU Length [cm] Width[cm] Height [cm] Weight

22 20 23 5kg

Code:

Date:

Version:

Page:



19/10/2017

1.1

31 of 61

Figure 4-3: ExoMars Phase B2 breadboard refurbished design with outer and inner (left) frame

4.1.2. OG3-OG6 INTERFACES OF PLANETARY TRACK

Interfaces that are not considered as baseline but may add additional value are marked as ‘Optional’.

Next, currently no OG3-OG6 provided hardware is foreseen. If required, related interfaces are also

marked as ‘Optional’.

4.1.3. OPERATIONAL INTERFACES

OG3-OG6/O/201/001/V0.1 – OG3 provided elements

Any OG3 provided hardware and software shall be agreed by OG6 before integration.

OG3-OG6/O/202/001/V0.1 – HCRU nominal operation

The HCRU shall be operated manually and carried by an operated respectively.

OG3-OG6/O/202/002/V0.1 – Rover nominal operation

The rover and PTU (if any) shall be operated in open loop and controlled by an operator via gamepad

OG3-OG6/O/202/003/V0.1 – Rover optional operation (Optional)

The rover and PTU (if any) shall be able to allow feeding in predefined trajectories.

OG3-OG6/O/203/001/V0.1 – Trajectory definition (Optional)

The manually definition (e.g. teaching) of trajectories shall be supported

4.1.4. FUNCTIONAL INTERFACES

OG3-OG6/F/201/001/V0.1 – HCRU parameters

The HCRU relevant parameters shall be provided to OG3 including but not limited to main dimensions, positions of sensors and markers and settings

OG3-OG6/F/201/002/V0.1 – Rover parameters

The rover relevant parameters shall be provided to OG3 including but not limited to main dimensions,

kinematics, positions of sensors and markers and settings

OG3-OG6/F/202/001/V0.1 Handheld Unit

OG6 provides, for the planetary scenario validation, a Handheld Central Rover Unit (HCRU) functionally representative to the ExoMars Rover and DLR-RM mobility standard in terms of relevant hardware and software architecture and perception sensor and therefore compatible with the ExoMars/LRU rover

OG3-OG6/F/202/002/V0.1 Rover unit

OG6 provides, for the planetary scenario validation, a planetary rover based on the DLR-RM mobility standard in terms of relevant hardware and software architecture and perception sensor and therefore compatible to the HCRU. If not agreed otherwise the ExoMars rover shall be used.

OG3-OG6/F/203/001/V0.1 – Lighting conditions

OG3 users will be able to choose from the possible lighting conditions provided by OG6 (COTS lighting system with standard light spectrum)

4.1.5. POWER INTERFACES

OG3-OG6/P/201/001/V0.1 – HCRU power interface (Optional)

If required, access to 12V (24V TBC with OG3) unregulated power may be provided by OG6 through

the HCRU (TBC with OG3).

OG3-OG6/P/201/002/V0.1 – Rover power interface (Optional)

If required, access to 24V (12V/48V TBC with OG3) unregulated power may be provided by OG6 through the ExoMars BB2.

Code:

Date:

Version:

Page:



19/10/2017

1.1

32 of 61

OG3-OG6/P/202/001/V0.1 – HCRU nominal additional power demand (Optional)

The nominal power demand of the OG3 provided components through the HCRU shall not exceed TBD W

OG3-OG6/P/202/002/V0.1 – HCRU maximum additional power demand (Optional)

The maximum power demand of the OG3 provided components through the HCRU shall not exceed TBD W

OG3-OG6/P/202/003/V0.1 – Rover nominal additional power demand (Optional)

The nominal power demand of the OG3 provided components through the ExoMars shall not exceed TBD W

OG3-OG6/P/202/004/V0.1 – Rover maximum additional power demand (Optional)

The maximum power demand of the OG3 provided components through the ExoMars shall not exceed

TBD W

4.1.6. MECHANICAL INTERFACES

OG3-OG6/M/201/001/V0.1 – HCRU mechanical interface (Optional)

The HCRU aluminium frame (ITEM Profile 5 20x20 TBC) shall be used to mount OG3 provided hardware (see http://www.item24.de/en/products/building-kit-systems/mb-building-kit-system.html).

OG3-OG6/M/201/002/V0.1 – Rover mechanical interface (Optional)

The ExoMars aluminium frame (ITEM Profile 5 20x20 TBC) shall be used to mount OG3 provided

hardware (see http://www.item24.de/en/products/building-kit-systems/mb-building-kit-system.html). The overall frame dimensions of the refurbished ExoMars rover (see Figure 4-3) are summarized below.

Table 4-2 ExoMars BB2 frame dimensions

BB2 Length [cm] Width[cm] Height [cm]

Outer frame 70 64 42

Inner frame 33 22 42


OG3-OG6/D/201/001/V0.1 – HCRU sensor data format

The HCRU sensor data format is TBD

OG3-OG6/D/201/002/V0.1 – Rover sensor data format

The rover sensor data format is TBD

OG3-OG6/D/201/003/V0.1 – Ground truth data format

The ground truth data format is TBD

OG3-OG6/D/202/001/V0.1 – HCRU sensor data

The HCRU sensor data shall be collected at a TBD frequency and provided offline to OG3

OG3-OG6/D/202/002/V0.1 – Rover sensor data

The ExoMars sensor data including rover proprioceptive sensor data shall be collected at a TBD frequency and provided offline to OG3

OG3-OG6/D/202/003/V0.1 – Ground truth data

The ground truth data shall be collected and provided offline to OG3

OG3-OG6/D/203/001/V0.1 – HCRU data interface (Optional)

OG3 provided sensors shall be directly connected to the HCRU via Ethernet UDP/TCPIP

OG3-OG6/D/203/002/V0.1 – Rover data interface (Optional)

OG3 provided sensors shall be directly connected to the HCRU via Ethernet UDP/TCPIP and the HCRU will be connected to the ExoMars rover (TBC with OG3)

http://www.item24.de/en/products/building-kit-systems/mb-building-kit-system.html

http://www.item24.de/en/products/building-kit-systems/mb-building-kit-system.html

Code:

Date:

Version:

Page:



19/10/2017

1.1

33 of 61


4.1.8.1. Inputs

The test inputs are the following:

1. Rover initial position and desired path

2. Rough reference terrain model

3. Terrain and object specification (if any)

4. Illumination conditions

4.1.8.2. Outputs

The test outputs are the following:

1. Successful recording of sensor data along path

2. Localizing rover pose and objects

3. Building a map of the environment

4. The Ground Truth data

4.1.8.3. Parameters

The parameters that will be provided by OG6 to OG3 are the following:

1. Rover kinematics

2. Position of visual markers and sensors.

3. Rough reference terrain model

Code:

Date:

Version:

Page:



19/10/2017

1.1

34 of 61


In the orbital OG3 validation the OOS-SIM facility will be used. The sensors which will be made available to the OG3, in agreement with the OG3 itself, are the stereo camera system on the Light-

Weight Robot end-effector and a LIDAR sensor, placed on the chaser (TBC) (see Figure 4-4).

Figure 4-4: Light Weight Robot mounted on the chaser satellite mock-up of the OOS-SIM facility. Also visible are the stereo camera system at the end-effector, the potential position of a LIDAR system and

the target satellite mock-up (on the left).

These sensors will of course be directed towards the target satellite mock-up, also shown in Figure 4-4. The latter can be either stationary, with respect to the chaser, or follow a free body dynamic

behaviour, typical of the orbital environment. The simulated angular velocity in typically limited to < 5o/s and the attitude is of course limited by the collision constraints of the facility. Similarly for the chaser-LWR system, a gravity-free dynamic behaviour can be simulated, to reflect the dynamics of a

free-flying robot. As such, different trajectories of the chaser and of the robot can be commanded, to achieve typical relative motions to the target.

Given these functionalities, the OG6 will prepare a set of trajectories which can capture possible scenarios of interest to OG3. These will be discussed with OG3 in due course and can range from simple approach manoeuvres of the chaser to an attitude controlled target, to complex robot grasping manoeuvres (however the approach to a preselected grasping point will only be considered, and not the following phases with contact), in which the target satellite might be tumbling and the chaser

control system might be switched off (free-floating dynamic behaviour). The tumbling motions of the target can also be varied, between a flat spin, to a full three-dimensional tumble.

Extensions of the OOS-SIM facility are also currently in discussion at the Robotics and Mechatronics Institute, in order to provide more realistic illumination conditions and more realistic structural

properties of the target satellite mock-up. A perimeter of black curtains will be installed to simulate an eclipse condition, as well as to eliminate undesired effects from external light sources (TBC). A robot end-effector light source will be available to operate in the eclipse conditions (TBC). A dedicated light

source will be made available, to reproduce the sun (TBC).

Code:

Date:

Version:

Page:



19/10/2017

1.1

35 of 61

4.2.1. OG3-OG6 INTERFACES OF ORBITAL TRACK


OG3-OG6/O/001/001/V0.1 – trajectory library

A set of representative trajectories for the chaser satellite, the Light Weight Robot and the target satellite on the OOS-SIM facility will be made available for taking measurements with the chosen sensor(s).

OG3-OG6/O/001/002/V0.1 – trajectory library contents

The contents of the resulting trajectory library will be discussed with OG3.

OG3-OG6/O/001/001/V0.1 – trajectory library viewing

The trajectories in the libraries will be viewable in a dedicated simulator.

OG3-OG6/O/002/001/V0.1 – OG3 provided elements

Any OG3 provided hardware and software shall be agreed by OG6 before integration.

OG3-OG6/O/003/001/V0.1 – open loop control

All the actors of the OOS-SIM facility shall be controlled in open loop and will allow feeding in of predefined trajectories.


OG3-OG6/F/001/001/V0.1 – commanding trajectories

OG3 users will be able to choose from the list of representative trajectories and repeat them at their will from the OBC which controls the facility.

OG3-OG6/F/002/001/V0.1 – lighting conditions

OG3 users will be able to choose from the possible lighting conditions provided by OG6.


OG3-OG6/P/001/001/V0.1

The power supply to all sensors will be accomplished through external cables (see Figure 4-4). The

power interfaces to sensors provided by OG3 (see list in OG3-OG6/M/001/001/V0.1) need to be specified.


OG3-OG6/M/001/001/V0.1

The mechanical interfaces for the sensors of interest are listed below:

1. DLR’s stereo camera at LWR end-effector: already implemented

2. OG3 LIDAR: a mechanical interface will be designed to accommodate the sensor on the front

surface of the chaser mockup, facing the target mockup (see Figure 4-4). Care will be taken

that this interface is rigidly attached to the base of the mockup (the end-effector of the KUKA

robot).


OG3-OG6/D/001/001/V0.1

Code:

Date:

Version:

Page:



19/10/2017

1.1

36 of 61

The data transmission to all sensors will be accomplished through external cables. The data transmission interfaces to sensors provided by OG3 (see list in OG3-OG6/M/001/001/V0.1) need to be specified. This will be accomplished after procurement of the sensor. Interfaces to DLR’s sensors

already exist.

4.2.7. SOFTWARE INTERFACES

OG3-OG6/S/001/001/V0.1

The driver for communication between OG6’s OBC and the sensor(s) provided by OG3 need to be specified (see list in OG3-OG6/M/001/001/V0.1). Interfaces to DLR’s sensors already exist.


4.2.8.1. Inputs

The tests may be specified by the following conditions:

1. Target satellite state (position, orientation, translational velocity, rotational velocity)

2. Chaser satellite state (position, orientation, translational velocity, rotational velocity)

3. Chaser satellite controller type (GNC on, GNC off)

4. Light Weight Robot approach manoeuvre (approach grasping point 1, approach grasping point 2, …)

5. Illumination conditions (eclipse, sun light, sun light direction)

For the first 4 of the points above, there will be representative trajectories, which can be visualized by the OG3 user in a simulation environment.

4.2.8.2. Outputs

For every commanded trajectory, a stream of sensor measurements will follow. The sampling time of the pose estimation is 10Hz. The sampling time of the LIDAR sensor is 3 Hz. The ground truth of the

measurements will have an accuracy of +/- 5mm.

4.2.8.3. Parameters

Parameters of the tests are described in Section 4.2.8.1. The positions and orientations of the mock-ups, as well as the position of the light source are dictated by the facility’s geometry. These will be

considered in the definition of the trajectory library. The translational velocity of chaser and target satellites is limited to < 5cm/s, however for operational times which are restricted by the workspace of the facility’s industrial robots. The angular velocity of the target is limited to < 5 o/s. The grasping point positions should optimally be defined in agreement with OG3. The sun light direction will be at

90 deg, 60 deg, 30 deg or 0 deg to the camera optical axis (TBC).

Code:

Date:

Version:

Page:



19/10/2017

1.1

37 of 61


In the orbital OG5 validation a dedicated robotic facility with a Light-Weight Robot (LWR) will be used. The task will first consist in connecting the robot with a dedicated end-effector to an APM payload, attached through OG5’s SIROM interface to a dedicated task-board. The end-effector and the APM

payload will also be provided by OG5, and connected through a SIROM interface. The LWR and the task-board will be provided by the DLR. Following the successful connection, the APM will be detached from the task-board and the robot will move it to a new position, where a second SIROM interface will be available. This architecture is shown schematically in Figure 4-5.

Figure 4-5: OG5 testing at OG6 facilities: architecture

The torque control capability of the LWR will be used to the advantage of the task execution, during the contact phases of the tasks described above. The robot will in fact be first controlled in open-loop position mode to the required positions for perming the closure of the SIROM interfaces. Note that, due to the high required positioning accuracy and to the lack of a visual servo, these positions will be

taught prior to the tests and the robot will then be controlled in repeatability with respect to them. Account will also be taken of the fact that throughout the test, the end-effector load will change substantially, due to the mass of the APM. As such, the resulting bending of the robot structure will inevitably have to be taken into account in the teaching phase prior to the tests.

When the grasping position will be reached, the SIROM interface will perform a cage grasping of the mechanical parts to be connected, however without contact. Following that, during the closure of the

interface, the robot will be switched to impedance control mode, to minimize the forces and torques

applied to the SIROM mechanical elements.

The APM will be equipped with a camera, which will be controlled by the OBC through a simple CAN communication link. The images will also be received by the OBC, through a 200Mbit/s SpW communication link and displayed on a screen. The SIROM interfaces will be operated by a second

Code:

Date:

Version:

Page:



19/10/2017

1.1

38 of 61

OBC (EGSE) provided by the OG5. The communication architecture is shown schematically in Figure 4-6.

Figure 4-6: Communication Architecture for OG5-OG6 (orbital)

4.3.1. OG5-OG6 INTERFACES OF ORBITAL TRACK


OG5-OG6/O/001/002/V0.1 – end-effector F/T sensor

6 DOF tip force/torque sensor data during testing shall be provided by OG6.

OG5-OG6/O/001/003/V0.1 – end-effector data

Data about the robotic arm tip position and orientation shall be provided by OG6.

OG5-OG6/O/003/001/V0.1 – test setup geometries

For open-loop manipulator control, the exact geometries of the test setup shall be provided by OG6.

Exact position of APMs relative to robot is needed for open-loop picking.

OG5-OG6/O/004/001/V0.1 – facility layout

The OG6 facility ICD (lay-out) shall be provided to OG5 by CDR. OG6 manipulator ICD shall be

available before PDR.

OG5-OG6/O/005/001/V0.1 – CAD model

CADs, a kinematic description (e.g. DH parameters), and data sheets from the robotic arm shall be

provided by OG6.

Code:

Date:

Version:

Page:



19/10/2017

1.1

39 of 61


OG5-OG6/F/001/001/V0.1 – end-effector

The OG6 facility shall include a robotic arm on which the OG5 end-effector shall be mounted.

OG5-OG6/F/002/001/V0.1 – task-board

The OG6 facility shall include a task-board onto which the OG5 APM shall be mounted.

OG5-OG6/O/003/001/V0.1 – OBC

The OG6 facility shall include an on-board computer (OBC). The OBC shall provide an M&C (monitoring

and control) application for communication with the APM. The OBC shall also retrieve the APM’s measurement data.

OG5-OG6/F/004/001/V0.1 – arm tasks

The OG6 robot arm shall be able to grasp, detach and relocate an APM from an initial to a final operational location.

OG5-OG6/F/010/001/V0.1 – APM transportation

The robotic arm provided by OG6 shall be capable to hold and transport one APM.

The estimated dimensions of the APMs are the following:

Orbital primary APM: (HxWxL) 150 x 150 x 150 mm

Orbital secondary APM: (HxWxL) 150 x 150 x 150 mm

OG5-OG6/F/005/001/V0.1 – robot control modes

The OG6 robot shall be controlled in position and in impedance control modes. The OG6 robot will be controlled in position mode till close to contact (i.e. till ready-to-capture identified by OG6) and then in

impedance mode (after captured state identified by SIROM) for the contact operations. No change in robot position shall occur when switching from position to impedance mode.

OG5-OG6/F/005/002/V0.1 – robot position control open-loop

The OG6 robot shall be controlled in open-loop when in position-control mode. The positions of both the base of the robot and APMs are pre-defined and hard-coded into the controller.

OG5-OG6/F/005/003/V0.1 – robot position control accuracy

The OG6 robot in position control mode shall have a position accuracy at SIROM interface coordinate

frame of:

+/- 5 mm in any direction

+/- 1º in any axis

+/-1 mm and +/-1 deg can be achieved by repeatability just by “calibrating” the manipulator at the beginning of OG5 tests in OG6. Although an accuracy of +/- 1mm and +/- 0.7 deg could be achieved with a visual servo, the latter will not be implemented in this test campaign. As such, the values +/- 1mm and +/- 1 deg. remain valid.

OG5-OG6/F/005/004/V0.1 – robot impedance control closed-loop

The OG6 robot shall be able to be controlled in closed-loop impedance control mode after SIROM

identifies captured state.

OG5-OG6/F/005/005/V0.1 – robot impedance control resistance forces/torques

The OG6 robot in impedance control mode shall limit the resistance torques and forces at SIROM interface coordinate frame to:

Code:

Date:

Version:

Page:



19/10/2017

1.1

40 of 61

Less than 10 N in any direction

Less than 0,5 Nm in any axis

OG5-OG6/F/006/001/V0.1 – robot load

The OG6 robot manipulator minimum load capacity shall be 10.5 kg (quasi-static).

OG5-OG6/F/007/001/V0.1 – robot collision avoidance

The OG6 robot controller shall include a collision avoidance functionality to ensure that during the relocation of the APM no collisions occur with the experimental mock-up.

OG5-OG6/F/007/002/V0.1 – envelope constraints

The OG5 shall provide envelope constraints (static and dynamic) of the APMs and end effector.

OG5-OG6/F/009/001/V0.1 – robot ready to capture signal

OG6 shall provide to OG5 ready-to-capture status when the robotic arm arrives to the ready-to-capture position of SIROM interfaces according to OG5-OG6/F/5/3/V0.1.


OG5-OG6/P/001/001/V0.1 – power cables

The two power interfaces between the OG5 SIROM Standard Interfaces, at the end-effector and at the

Active Payload Module (APM), and the power supply provided by OG6 consists of external cables. These are sustained by the Robotic Arm itself. The cables are fixed along the Robotic Arm with glued fixtures and Velcro stripes (see Figure 4-7). The cables are provided by OG5.

Figure 4-7: The weight of the cables sustained by the Robotic Arm. When the payload (blue) is removed, the cables (black) does not fall down. This implies that the cables themselves are sustained

by the glued fixtures and Velcro stripes.

OG5-OG6/P/002/001/V0.1 – power requirements SIROM

The power supply of the SIROM is 24 V DC.

OG5-OG6/P/003/001/V0.1 – power requirements APM

The power supply of the APM is TBD V


OG5-OG6/M/001/001/V0.1 –end-effector interface to robot

The OG6 manipulator shall include a suitable mechanical interface to mount the end effector provided

by OG5.

Code:

Date:

Version:

Page:



19/10/2017

1.1

41 of 61

OG5-OG6/M/002/001/V0.1 – robot output force

The output flange of the Robotic Arm used in the simulated environment shall be able to exert a force

of 150 N in any direction. This includes the dynamic (inertial) forces delivered by the manipulator due to accelerations of the APM mass. For the limit value of the mass of the end-effector load, see OG5-OG6/F/006/001/V0.1.

OG5-OG6/M/002/002/V0.1 – robot output torque

The output flange of the Robotic Arm used in the simulated environment shall be able to exert a torque of 25Nm in any direction.

OG5-OG6/M/003/001/V0.1 – robot attachment points

The Robotic Arm used in the simulated environment shall offer one or more attaching points to sustain the cables of the SIROM End Effector EGSE harness within 30 cm max from the output flange of the Robotic Arm itself. This shall be valid for any attitude of any Robotic Arm's joint.

OG5-OG6/M/004/001/V0.1 – interface LWR to OG5 end-effector

The mechanical interface of the Light-Weight Robot, which will be used to accommodate the end-effector produced by OG5 (SIROM), is described in Figure 4-8.

Code:

Date:

Version:

Page:



19/10/2017

1.1

42 of 61

Figure 4-8 Output Flange of DLR Light-Weight Robot with bolt pattern

Refer to Figure 4-8, FWA 50 (right). DLR provides this flange. The OG5 device should comply to DIN ISO-9409, as shown in the figure. It needs to have four threaded holes (pcd 50, M6, 8mm depth) (see 33), the 6 mm H7 hole (8mm depth for orienting pin) (see 73) and the 31.5 h7centering stud (maximum length 3mm) (see 78). The pin (see 73) is directed in the +ve x-direction. The z-axis is the axis of symmetry, +ve inwards into your device (into the page for given figure).

OG5-OG6/M/005/001/V0.1 – interface APM to task-board

OG6 facility task board shall provide 3 M6 (TBC) I-F threaded holes for attaching each of the two non-active I/F elements (provided by OG5) onto which the OG5 APM’s SIROM I-F can be accommodated. These threaded holes shall be equally distributed (at 120º) over a 200 mm (TBC) diameter circumference.


OG5-OG6/D/001/001/V0.1 – SpW link

The OG6 OBC shall provide SpW-PnP communication protocol used for data interface with the APM.

THE OBC shall not contain apply SpW. Instead, the SpW data shall be converted to ETHENET by a dedicated ESL box. Harness and connectors shall be provided by OG6 to connect the OBC with the

Code:

Date:

Version:

Page:



19/10/2017

1.1

43 of 61

SIROM (the APM data harness passes through the SIROM). The data communication shall be 200 Mbit/s.

Due to the high costs of the ESL, only one is in plan to be used, for one APM. If there is necessity to

test two APMs, the same harness/converter will be used and the tests with it will be repeated, while first connected to one and then to the other APM.

OG5-OG6/D/001/002/V0.1 – CAN link

The OG6 OBC shall provide CAN communication protocol used for data interface with the APM controller. This will be used to send simple commands to the APM camera. Harness and connectors shall be provided by OG6 to connect the OBC with the SIROM (the APM controller harness passes

through the SIROM).

OG5-OG6/D/001/002/V0.1 – data cable OBC/EGSE.

No interfaces are foreseen between the OBC and the EGSE.

OG5-OG6/D/003/001/V0.1 – Monitoring interface

A monitoring interface (HMI) capability to control the APM M&C Application shall be provided by OG6.

OG5-OG6/D/004/001/V0.1 – data cables

The data transfer interface (Ethernet connection) between the OG5 end-effector (SIROM) and the OG5 Active Payload Module (APM) produced by OG5 and the on-board computer (OBC) provided by OG6 at the orbital facility consists of external cables. These are sustained by the Robotic Arm itself. The cables are fixed along the Robotic Arm with glued fixtures and Velcro stripes (see Figure 4-7). The

cables are provided by OG5.

OG5-OG6/D/005/001/V0.1 – world model

The world model is predefined and stored in the robot controller (Matlab Simulink block). This includes the positions of the robot end-effector which the robot controller has to reach, for each preplanned pick-and-place task. These are function of the given positions of the APM sockets on the satellite mock-up and dimensions of the SIROM and APM. For collision avoidance purposes, “no-go” areas are

also included in the world model.

4.3.7. SOFTWARE INTERFACES

OG5-OG6/S/001/001/V0.1

The OG5 SIROM devices are controlled by OG5, through the EGSE, and not by OG6.


4.3.8.1. Inputs

The test inputs are the following:

4. Positions of APMs on task-board

5. Size of APMs.

6. Position of SIROM interfaces of APMs.

7. Robot configurations equivalent to positions of SIROMS adequate for establishing connections

of interest (these are: between end-effector and APM, between APM and task-board), function of points 1, 2, and 3 above. These configurations are stored in the robot controller.

4.3.8.2. Outputs

The test outputs are the following:

5. Successful connection between robot end-effector and APM

6. Successful transportation of APM to new position (pick-and-place task)

Code:

Date:

Version:

Page:



19/10/2017

1.1

44 of 61

7. Successful connection between APM and task-board

8. Successful camera image transmission to OBC for display on screen.

4.3.8.3. Parameters

There are no test parameters in plan for the moment.

Code:

Date:

Version:

Page:



19/10/2017

1.1

45 of 61

5. DFKI FACILITIES


5.1.1. DESCRIPTION

For the evaluation of OG2 in the planetary track, DFKI will provide the SherpaTT rover. This 4-wheeled planetary exploration rover has an actuated suspension system developed for high mobility in irregular terrain. This enables the rover to use energy efficient wheeled locomotion to cover long

distances, and at the same time to negotiate difficult terrain by dynamically adapting the wheel suspension to slopes and obstacles.

The dynamic locomotion control can be configured to exhibit different locomotion modi and behaviours. For the purpose of testing the OG2 autonomy module in FACILITATORS, the dynamic locomotion control will be adapted to mimic the behaviour of a rover like the ExoMars rover.

SherpaTT’s overall weight is about 165 kg. Due to self-locking gears in the four suspension units, the rover is able to cope with high additional payload weights without increasing energy consumption to

maintain the current robot’s body pose.

Figure 5-1: SHERPA_TT rover

Code:

Date:

Version:

Page:



19/10/2017

1.1

46 of 61

Figure 5-2: SherpaTT construction drawing & definition of x-y-plane

Figure 5-3: SherpaTT control structure

Code:

Date:

Version:

Page:



19/10/2017

1.1

47 of 61

Figure 5-4: SherpaTT electronics overview (simplified)


Rover Unit: OG6 provides, for the planetary scenario validation, a planetary rover based on the DFKI SherpaTT rover. (OG2-OG6/F/201/001/V0.1 Rover unit)

Rover Parameters: The rover relevant parameters shall be provided to OG2 including but not limited to main dimensions, kinematics, positions of sensors and markers and settings (OG2-OG6/F/202/001/V0.1 – Rover parameters)

ExoMars-analogue Locomotion: The rover locomotion system features four legs with in-wheel

drives and actuated joints. For the OG2 validation experiments, this locomotion system shall be constrained to mimic the behaviour of an ExoMars-like exploration rover.

API to Rover 2D Motion: The SHERPA operating system (ROCK) will provide an interface for OG2 to control rover locomotion (OG2-OG6/F/1/1/V0.1 - Planetary – Rover - 2D Motion command interface). This interface will be provided as a C++ Library for controlling SherpaTT remotely. It Will allow to:

Send motion commands to the mobile base

Send joint commands to the manipulator

Receive sensor and map and telemetry data

Code:

Date:

Version:

Page:



19/10/2017

1.1

48 of 61

Linux PCOG X Software

SherpaTTTele-Client

(C++)

SherpaTT PC

ROCK

SherpaTTTele-API

In: TC

Out: TM

Ethernet

Figure 5: SherpaTT teleclient C++

This SherpaTT Remote API is provided as C++ Library and can be used to control the robot from external software, as shown in Figure 8-6

+getRoverPose() : Pose+getManipulatorJointState() : Joints+getMobileBaseJointState() : Joints+getFrontalCameraImage() : Image+getGripperCameraImage() : Image+getIMUData() : IMU+getDEM() : DEM (TBC)+getDGPS() : DGPS+sendMotion2D(eing. command : Motion2D)+sendManipulatorJointCommand(eing. command : Joints)

SherpaTTTeleClient

+position : Vector3+orientation : Quaternion+referenceFrame : string+frameName : string

Pose

+x : double+y : double+z : double

Vector3 +x : double+y : double+z : double+w : double

Quaternion

DEM (TBC)

+time : long+latitude : double+longitude : double+noOfSatellites : int+altitude : double+geoidalSeparation : double+ageOfDifferentialCorrections : double+deviationLatitude : double+deviationLongitude : double+deviationAltitude : double

DGPS

+time : long+acc : Vector3+gyro : Vector3+mag : Vector3

IMU

+translation : double+rotation : double+headingRadians : double

Motion2D

+time : double+width : double+height : double+isRGB : bool+isGreyscale : bool+data : char[]

Image

+time : long+jointStates : JointState

Joints

+position : long+speed : double+acceleration : double+effort : double

JointState

Figure 6: Methods of SherpaTT TeleClient and its data types

On-Board CPU for ERGO: The SherpaTT will feature an on-board CPU dedicated to host the OG2 software (ERGO) (OG2-OG6/F/5/0/V0.1)

Provision of DTMs and orbital maps of the analogue site: OG6 will provide detailed DTMs and other digital maps (e.g. satellite images / maps) of the analogue test site to be stored and managed by the OG2 ERGO software module. (OG2-OG6/F/4,5/0/V0.1).

Code:

Date:

Version:

Page:



19/10/2017

1.1

49 of 61



Rover Power Interface: If required, access to 44,4V/10Ah DC power can may be provided by OG6 through the SherpaTT. (OG2-OG6/P/201/001/V0.1 – Rover power interface)

Additional Power Demand by OG2: The nominal power demand of the OG2 provided components shall not exceed 50 W (OG2-OG6/P/202/001/V0.1 – Rover nominal additional power demand)

5.1.3.2. Mechanical interfaces

No specific mechanical interface is necessary to integrate the OG2 CPU in the rover body.


Sensor Equipment and Formats: The SherpaTT features the following sensors that can be accessed through the SherpaTT operating system:

LIDAR (Velodyne HDL-32);

Laser Range finder (Hokuyo UST-20LX)

Camera (Basler Ace; 2048x2048px, 25fps, b/w)

Attitude & Heading (Xsens MTi-300)

F/T Legs (FT-DELTA 160)

F/T Arm (FT-mini 45) part of manipulator interface

Ground Truth Data: A DGPS unit will be added to provide exact position data / ground truth data. (OG2-OG6/D/6/1/V0.1). This unit will provide the following data:

Spatial Dual by Advanced Navigation (featuring GNSS and in addition accelerometer, gyroscope, magnetometer, pressure sensor);

base/samples/IMUSensors (raw values and calibrated values)

base/samples/RigidBodyState (pose including gps position)

GPS/Solution (gps position with number of satellites etc.)

API to 2D Position and Heading (OG2-OG6/D/1/1/V0.1): Rover positon and heading will be provided to OG2 through the interface to the DGPS and (if needed) to the Xsens sensor.

API to On-Board Camera Images (OG2-OG6/D/2/1/V0.1): Monocular images will be provided to OG2 through the interface to the on-board camera. Stereo-images are not available.

Communication Interfaces: SherpaTT features the following interfaces for communication between external and rover, internal communication, and communication with payloads:

External and internal communication interfaces

External wireless (2,4 GHz WiFi 802.11n)

External cable connection (GbE) providing Ethernet (100 Mbits/s), control PC and modular

interfaces

Internal Joint Communication (for legs and arm) using NDLCom via LDVS. This protocol was developed by DFKI

100 Mbits/s Ethernet Communication (for communication between OG2 CPU and SherpaTT CPU)

Remote energy switch (868 MHz Xbee-Pro)

Interfaces for communication between rover and payloads:

Code:

Date:

Version:

Page:



19/10/2017

1.1

50 of 61

No interfaces for communication with the SIROM payloads are provided so-far. SpaceWire and CAN communications can be installed, but the interfacing with the SherpaTT operating system will need some investments (hardware) and development efforts.


5.1.5.1. Inputs

The inputs required by OG6 are:

- An image of the OG2 software to be implemented on the selected OBC with the existing

relevant interfaces to the rover operating system.

5.1.5.2. Outputs

The outputs of the test will consist of:

- A documentation of the trajectory followed by SherpaTT under the guidance of the OG2 autonomy software module. This includes a comparison of the planned trajectory and the trajectory actually followed by the rover.

- A complete video-stream of the exploration mission from the on-board camera.

- A documentation of re-planning processes triggered by external events (e.g. detection of

obstacle). This has to be logged/provided by OG2.

Code:

Date:

Version:

Page:



19/10/2017

1.1

51 of 61


5.2.1. DESCRIPTION

The SherpaTT rover is equipped with a robotic manipulator. This robotic arm has 6 DOF and a length of more than 1,5 m. The maximal dynamic payload is 25kg.

The robotic arm is currently able to perform closed-loop control using visual servoing. However, for this functionality the arm makes use of a camera integrated in the interface unit mounted on the tip of

robotic arm. Other cameras or exteroperceptive sensors (e.g. for collision avoidance) are not integrated in the arm. If closed-loop impedance control and closed-loop visual control of the arm is needed to fulfil the tight positioning requirements imposed by SIROM, a torque/force sensor (for impedance control) and a camera (for visual survoing) will have to be integrated in the SIROM end

effector. Markers will have to be added to the APMs.

Figure 5-7: SherpaTT manipulator dimensions


Rover-mounted Robotic Arm: With SherpaTT, OG6 will provide a robotic arm mounted on a mobile robotic rover with a payload capacity exceeding 15 kg (OG5-OG6/F/1/2/V0.1), (OG5-OG6/F/5/2/V0.1). The standard payload is 25 kg.

On-Board CPU for M&C Application: OG6 will provide a dedicated on-board computer (OBC), or sufficient space on the standard SherpaTT OBC, to host the OG5 monitoring and control (M&C) application. The M&C application is used to control the APMs and to receive data (camera images) from the APMs through the SIROM STD I/F. (OG5-OG6/F/2/1/V0.1).



Robotic Manipulator Standard Power Interface: To power an end-effector or a payload, the manipulator features an interface to the rover’s main power bus, with 44.4 V nominal voltage and 10 A.

5.2.3.2. Mechanical interfaces

Robotic Manipulator Tip Mechanical Interface: The mechanical interface to connect the OG5 end-effector to the manipulator is a flange with 6 M3 screws (thread depth 5 mm) on a circle (r = 19,62 mm), but are not equally spaced (see below). Note that in the standard interface, the holes are not

equally spaced. (OG5-OG6/M/1/1/V0.1)

Attaching Points for Cables: The cables providing the link from the APM M&C unit to the end-

effector will be mounted to the outside of the robotic arm. Attaching points to mount the cables will be available. (OG5-OG6/M/3/1/V0.1)

Code:

Date:

Version:

Page:



19/10/2017

1.1

52 of 61

Figure 5-8: Manipulator arm flange for mounting an end-effector to the tip of the robotic arm

Interface for Auxiliary APMs: The SherpaTT rover features four holding-bays / slots that can be used to take up the auxiliary APMs (see below). The dimensions of these slots are 15 x 15 x 15 cm. The slots will be adapted to hold a SIROM interface. (OG5-OG6/F/2/2/V0.1)

Figure 5-9: SherpaTT main frame with mounted manipulator and slots for APMs (blue)

Interface for Primary APM: On the underside of the SherpaTT body, an interface to hold the

primary APM will be included. The specifications of this interface are TBD. (OG5-OG6/F/2/2/V0.1)


Data Interfaces OBU / M&C – Payload: SIROM foresees SpaceWire (SpW) and CAN for communication between the OBU hosting the APM M&C software module (and the HMI) and the End-Effector mounted on the tip of the robotic arm. The respective cables can be attached to the robotic arm. The SherpaTT OBU currently does not support SpW or CAN. However, the OBU can be modified to support the protocols with some (financial) effort. (OG5-OG6/D/1/1/V0.1, OG5-OG6/D/1/1/V0.1)

Internal Manipulator Communication Interfaces:

- A communication protocol develop at DFKI (the LVDS protocol) is available for communication between joints and sensors.

- A RS422 connection to the CMMB is available.

Code:

Date:

Version:

Page:



19/10/2017

1.1

53 of 61

Force/Torque Sensor in End Effector: A ATI Mini 85 SI-950-40 (http://www.ati-ia.com/products/ft/ft_models.aspx?id=Mini85) force/torque sensor will be integrated in the End

Effector by OG5. This sensor is rated at 950 N and 40 Nm. Precision will be sufficient to fulfil SIROM requirements (OG5-OG6/O/1/2/V0.1)

Sensors to measure pose (IMU): An IMU to measure pose is available in the rover, but not in the robotic arm or in the individual joints. Pose of the arm / end effector can be calculated using forward kinematik (OG5-OG6/O/1/1/V0.1)

Realtime Measurements of Joint Parameters: Joint parameters such as position, velocity, current

(electricity), and temperature can be delivered in real-time. The format is TBD (OG5-OG6/D/2/1/V0.1)

Tip Position and Orientation: Position and orientation of the robot arm tip can be delivered in real time. Format is TBD (OG5-OG6/O/1/1/V0.1)

M&C HMI: SpW, power, CAN will be tested at OG6 with EGSE from OG5. (OG5-OG6/D/3/1/V0.1)


5.2.5.1. Inputs

Position Coordinates for APM / STD I/F: Exact position coordinates (+/- 1mm xyz, +/- 0,05 deg)

of the SIROM STD I/F on the auxiliary APM relative to a fixed reference point on the rover have to be

fed to the trajectory planner of the robotic arm.

SIROM Controller TC Messages: No I/F foreseen between SIROM Controller and OG6. After SIROM actuators movements, the commands to be delivered to the robotic arm controller (e.g. Pass to impedance mode) will be manually introduced by the OG6 operator after verbal confirmation from SIROM EGSE (that will be checked in the SIROM EGSE HMI).(OG2-OG5/F/2/2/0.1)

5.2.5.2. Outputs

Manipulator and STD I/F Status Information: Information regarding the position and status of the manipulator and the STD I/F (e.g. ready-to-capture) is provided to the SIROM Controller TC. (OG2-OG5/F/2/2/0.1)

http://www.ati-ia.com/products/ft/ft_models.aspx?id=Mini85

http://www.ati-ia.com/products/ft/ft_models.aspx?id=Mini85

Code:

Date:

Version:

Page:



19/10/2017

1.1

54 of 61

6. AIRBUS FACILITIES



The objectives of the OG1 validation for the planetary track are to demonstrate the operation of ESROCOS for the monitoring and control of a mobile platform representative of current and future planetary rovers.

The testing scenario will see ESROCOS being hosted on a space-representative on-board computer (OBC) that will be interfaced to the mobile platform for commanding as well as acquiring data from a

camera. The system will be tested in a representative environment to simulate typical inputs the OBC would acquire on a real setup.

The validation/testing activities to be conducted within OG1, using the facilities, assets and support from FACILITATORS, will focus of demonstrating the suitability and capability of ESROCOS to perform

a range of functions representative of Rover platform control and operation. The validation will therefore concentrate on:

Operation of ESROCOS on a space-representative OBC: GR712

Operation of the rover platform in Ackermann and point-turn modes

Acquisition of platform telemetry during traverse

Acquisition of camera images by the OBC

Actuation of a device on a CANbus

Figure 6-1: OG1 Planetary - Bridget rover Testbed platform supporting OG1 tests

Code:

Date:

Version:

Page:



19/10/2017

1.1

55 of 61

Rover System

Remote Control PC

ESROCOS

Space representative

ComputerRTEMS

ESROCOS

Rover Vehicle

Platform manager

Locomotion Computer

CAN Node

Pan and Tilt Unit

Locomotion System

Actuator

Camera

Camera

Ethernet

CAN

Sensors

Sensors

Position Sensors

ESROCOS System Main ESROCOS System interfaces Actuator – TC recipient Sensor – TM Generator

COTS Computer

(Linux)

ESROCOS

Ethernet

Serial

Ethernet

OG1 Camera (I/F TBC)

ESROCOS

Figure 6-2: OG1 Planetary - Validation Scenario Setup at Airbus DS



Rover

Pending on its accommodation, the representative OBC will be powered through a 12/24V bus onboard the rover down-converted and regulated to 5V as per OBC requirement. Alternatively, for extensive testing a 220V tether will be provided with 5V regulation.

The OBC will interface to the rover onboard router with a standard RJ45 Ethernet cable. This

will enable the OBC to connect to:

o The Bridget Platform manager through a TCP/IP interface

o The remote “operation computer” that will send the command load to the OBC

o Possibly an additional Ethernet camera provided by OG1

A DSUB9 CANbus connector to interface the OBC to the CAN node

Remote Control Station

The Remote control station will be provided with 220V

The remote “Operation computer” will connect to the Remote control router through an RJ45 Ethernet cable. The router will assure the high speed bridging to the Rover router

6.1.2.2. Mechanical Interfaces - Accommodation of the OBC

Space representative OBC - The proposed mounting of the OBC enclosure is TBC pending

on volume and mounting point arrangement. It will be accommodated ini the front loading bay. However, should the GR712 board be selected, access to the onboard selection jumpers of the board should be reasonably accessible.

COTS Linux PC - The second COTS Linux PC will be loaded with an ESROCOS image and will

interface with the Ethernet-based systems. It will be accommodated in the front payload bay.

Code:

Date:

Version:

Page:



19/10/2017

1.1

56 of 61


6.1.3.1. Locomotion Platform

The locomotion system is controlled through a TCP/IP interface with the Platform manager PC that relays the data to the locomotion system PC.

The interface is described in the Bridget Rover hardware and Software ICD in [RD.1].

The OBC can send a number of telecommands (TC) to the rover platform to perform Ackermann and

point turn commands. The telemetry (TM) from the rover platform is sent back to the OBC including:

Speed of each driving wheel

Position of each driving wheel

Current from each driving wheel

Position of each Steering Drive

Converted Angle of each steering drive

Current from each steering drive

System Current and Voltage

Locomotion Mode

Errors and faults

…

6.1.3.2. Camera System

The Camera system comprises a pair of cameras and a Pan and Tilt Unit that are controlled through a TCP/IP interface with the Platform Manager PC on onboard the rover.

Note: The interface definition is in progress and will be described in the Bridget Rover Hardware and

Software ICD in [RD.1].

The TC commands the pan and tilt angles of the PTU as well as capturing images from the set of cameras. The TM returned includes the current PTU angles and the images from the cameras.

6.1.3.3. CAN Node

A minimum of 1 CAN Node will be provided to allow the testing of the CANBus management by the OBC. The Node will control a mechanical actuator that will be located on the rover.

TMs will be sent to the node for actuation and TM with position feedback will be provided.

Note: The interface definition is in progress and will be described in the “CAN Node Software ICD” document in [RD.3]


6.1.4.1. Inputs


An image of ESROCOS to be implemented on the selected representative OBC with the existing relevant interfaces to CAN node and serial connection to the ESROCOS Linux PC

An image of ESROCOS to be implemented on the selected COTS Linux PC with the existing

relevant interfaces to the other rover systems including locomotion, cameras and PTU

Code:

Date:

Version:

Page:



19/10/2017

1.1

57 of 61

A remote control computer to send commands to the OBC that will be plugged into the local control network infrastructure.

6.1.4.2. Outputs

The test output will consist of the TC and TM load stored onboard the OBC that comprises the TM from the Locomotion system, camera system and CAN Node over time.

The data will be retrieved through the network connection to the rover OBC.



Similarly to the Orbital track validation, the objective of the OG4 testing focuses on the validation of the Inspection Sensors Suite (ÏNSES) constituting of the basic bricks for enabling advanced perception and navigation functionalities, in this case, for planetary scenarios. This includes the integration and use of a wide range of sensors, including, but not limited to: Multispectral Stereo Camera, Hi-Res Camera, LIDAR, Radar, Ultrasound/Sonar, Contact/Tactile, Force/Torque, Inertial Measurement Unit (IMU), Star tracker or sun sensor.

The sensors suite from OG4 will include redundancy and will be based on modularity and plug-in concept enabling its re-configurability. The INSES will have standardized interface for communicating with other OGs elements

The objectives of OG4 validation in the planetary track are to:

Verify that the sensor suite is re-configurable and satisfy the modularity / plug-in concept.

Verify that the sensor suite provides measures as expected in a planetary scenario setup.

Verify the sensor suite compatibility and its various interfaces (power, electrical, data, thermal): functional test only

The validation/testing activities to be conducted within OG4, using the FACILITATORS facilities, will focus on the acquisition of a number of datasets from the Airbus Mars Yard test area with the INSES

mounted on a mobile platform in different lighting conditions. To validate the capability of the INSES to provide accurate position information to the rover during traverse, the location of the platform during the test will be provided by the facility Ground truth position system that will enable accurate correlation of the test data.

Figure 6-3: OG4 Planetary – OG4 Test Area at Airbus DS

Code:

Date:

Version:

Page:



19/10/2017

1.1

58 of 61



Rover

Pending on its design and accommodation options, the INSES will be powered through an unregulated 12/24V power rail on board the rover as described in [RD.1]. Alternatively, a 220V mains tether will be provided.

No interfaces are anticipated between the rover systems and the INSES

The INSES control unit can be connected to the Rover on board router for remote commanding

through a RJ45 Ethernet connection.

Remote Control Station

The control of the INSES can either be performed close to the rover or through a Remote control station. The remote “Operation computer” will connect to the Remote control router through an RJ45 Ethernet cable. The router will assure the high speed bridging to the Rover router.

6.2.2.2. Mechanical Interfaces - Accommodation of the OBC

The proposed mounting of the INSES is TBC pending on volume and mounting point arrangements and whether the INSES is composed of a single or multiple units to be accommodated.

The mechanical arrangement of the payload bays are provided in [RD.1]. However these can

be reconfigured if necessary.


No data interfaces are anticipated to be required between the system provided by OG4 and OG6.

Both the INSES control computer and the rover Ground Truth system will need to be time synched before each test (e.g. through a NTP server).


6.2.4.1. Inputs


The necessary volumes and masses of the unit/units sufficiently ahead of integration to maximise the placement of the INSES and to undertake the necessary modifications to the platform if necessary.

The required lighting setups required during testing – location, intensity, etc

6.2.4.2. Outputs

The outputs of the test will consist of:

The data generated by the sensors on board the INSES

The Ground Truth data, provided for each test, as a text file including all 6DOFs of the rover

platform during testing again a timestamp. The data will be retrieved from the Platform Computer after each test. The position system and its reference frames are described and discussed in [RD.3]

Code:

Date:

Version:

Page:



19/10/2017

1.1

59 of 61

0 0

0 -12

-1

0

1

2

3

4

5

6

7

8

9

10

11

12

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

-Y [

m]

X [m]

Figure 6-4: Mars Yard Frame definition - Shaded area denote sloped banks

The data packet from the Ground Truth will be provided at 120Hz with the format:

Az El Rl X Y Z

Where, following the sensor nomenclature:

Az - is the Azimuth (Yaw)

El - is the Elevation (Pitch)

Rl - is the Roll

X - is the X distance from the N-Frame origin

Y - is the Y distance from the N-Frame origin

Z - is the Z distance from the N-Frame origin

X

Y

Z

Code:

Date:

Version:

Page:



19/10/2017

1.1

60 of 61

7. CONCLUSIONS

This document describes the interfaces to the facilities that will be made available by FACILITATORS to the other parallel projects (OG1 to OG5) for their validation, in the frame of the Space Robotics

Technologies Cluster.

The document will be updated along the project course, as the facilities are designed in detail to host the tests and in case of any facility enhancement or upgrade.

Code:

Date:

Version:

Page:



19/10/2017

1.1

61 of 61

END OF DOCUMENT