Capabilities between Remote Robotic
Systems and the METERON Infrastructure
Victor Zamora Merino
Space Engineering, master's level (120 credits) 2018
Luleå University of Technology
Control Capabilities between Remote
Robotic Systems and the METERON
Infrastructure
Written by
Victor Zamora Merino
Dr. Jennifer Kingston
Cranfield University
Course Director of MSc Astronautics and Space
Engineering
Prof. Dr. Anita Emark
Lulea University of Technology
Department of Computer Science, Electrical and Space
Engineering
Dr. Merhan Sarkarati
European Space Operations Centre
2
Abstract
The following paper explains the development of key components comprised in the infrastructure of the Multipurpose End-To-End Robotics Operations Network, or METERON for short. This project has been conducted by the European Space Agency in collaboration with multiple other international agencies to set the ground base of robotic space exploration in the following decades. The ultimate goal of this project is to design a framework to be used as a starting point for space exploration missions in the future.
The design team of METERON infrastructure envisioned the future exploratory missions to be conducted as a combination of human explorers and robotic entities. This collaboration should be practical and effortless to help maximize the efficiency of the missions. Currently, the METERON Project is finishing the development phase of the basic infrastructure by completing the design and integration of most of the components involved. This thesis work focuses on one of the many areas required to carry out this joint venture between astronauts and robotic assets. It aims to develop the communication framework to enable monitoring and control capabilities between these robotic assets and the main control system. On the one hand, the main control system of the framework has been designed to channel all communications with other entities of the infrastructure via robotic services. On the other hand, the robotic assets are expected to be developed by other collaborative entities participating on the project (other space agencies or private companies). Due to the diversity of sources from which the robotic assets could come from, the development of an adaptive interface between these assets and the main control system becomes necessary.
3
Table of contents
Abstract ... 2 Table of contents ... 3 Table of figures ... 7 Acronyms ... 8 1. Introduction ... 10 1.1 Objectives ... 10 1.2 Requirements ... 10 1.3 Structure ... 11 2. Relevant projects ... 12 2.1 METERON Project ... 12 2.1.1 Overview ... 12 2.1.2 Possible scenarios ... 13 2.1.3 Validation ... 14 2.2 MARVIN Project ... 15 2.2.1 Overview ... 15 2.2.2 Possible scenarios ... 15 2.2.3 Validation ... 16 3. Theoretical background ... 193.1 METERON Operational Environment ... 19
3.2 METERON Operations Software ... 21
3.3 METERON Robotic Services ... 22
3.4 Robot Operating System ... 25
3.5 GAZEBO Simulator ... 26
3.6 Interplanetary Overlay Network ... 27
3.6.1 Overview ... 27
3.6.2 Features ... 28
3.6.3 Bundle Protocol ... 28
4 4.1 Overview ... 30 4.2 Software architecture ... 30 4.2.1 Generic implementation ... 31 4.2.2 MOCUP Implementation ... 31 4.3 Software language ... 32 4.4 Development outline ... 33 5. Generic implementation ... 34 5.1 MRS-ROS Adapter ... 34 5.1.1 Overview ... 34 5.1.2 Package function ... 35 5.1.3 Components ... 36 6. MOCUP Implementation ... 44
6.1 Plugin for MRS-ROS Adapter ... 45
6.1.1 Overview ... 45 6.1.2 Package function ... 46 6.1.3 Components ... 47 6.2 NXT-ROS Adapter ... 47 6.2.1 Overview ... 47 6.2.2 Package Function ... 48 6.2.3 Components ... 48 6.3 MOPS-ROS Adapter ... 49 6.3.1 Overview ... 49 6.3.2 Package Function ... 50 6.3.3 Components ... 51
7. Testing and validation ... 53
7.1 Validation of generic implementation ... 53
7.1.1 Setup ... 53
7.1.2 Telemetry test ... 53
5
7.1.4 Locomotion test ... 55
7.1.5 File test ... 55
7.1.6 Camera test ... 56
7.1.7 Video service test ... 57
7.2 Validation of MOCUP implementation ... 58
7.2.1 Setup ... 58
7.2.2 Locomotion test ... 58
7.2.3 Camera test ... 59
7.3 Validation of multiple assets ... 60
7.3.1 Setup ... 60
7.3.2 Execution ... 60
8. Discussion and Conclusions ... 62
8.1 METERON Components... 62
8.1.1 METERON Operational Environment (MOE) ... 62
8.1.2 METERON Robotic Services (MRS) ... 63
8.1.3 METERON Operations Software ... 64
8.2 Robot Operating System ... 64
8.3 Adapter for generic implementation ... 65
8.4 MOCUP implementation ... 66
9. Future development ... 67
9.1 METERON Project ... 67
9.2 METERON Operational Environment ... 67
9.3 METERON Robotic Services ... 68
9.4 METERON OPERATIONS SOFTWARE ... 68
9.5 Generic implementation of the adapter ... 69
9.6 MOCUP implementation of the adapter ... 69
9.7 New capabilities ... 69
9.7.1 Odometry improvement ... 69
6
7
Table of figures
Figure 1. METERON's Infrastructure basic scenario ... 13
Figure 2. METERON's Infrastructure with hub in foreign planet ... 14
Figure 3. Rovers used for validation: MOCUP (left) and EGP (right)[3] ... 15
Figure 4. Overview of operations scenario[7] ... 16
Figure 5. JACKAL rover by Clearpath Robotics[8] ... 17
Figure 6. Model of current configuration of the JACKAL rover[9] ... 17
Figure 7. GAZEBO simulation of the JACKAL rover ... 18
Figure 8. Software representation of METERON's infrastructure ... 19
Figure 9. Commanding view of MOE ... 21
Figure 10. Monitoring view of MOE ... 21
Figure 11. GUI of METERON Operations Software ... 22
Figure 12. Layered architecture of MO framework[3] ... 23
Figure 13. Connections of MRS Deployment[14] ... 24
Figure 14. ROS components[15] ... 25
Figure 15. GAZEBO simulation of JACKAL rover... 27
Figure 16. Required adapters for direct and relay links ... 31
Figure 17. MRS-ROS Adapter ... 31
Figure 18. Additional components for MOCUP's implementation ... 32
Figure 19. MRS-ROS Adapter basics ... 34
Figure 20. MRS-ROS Adapter’s communication with METERON's infrastructure ... 35
Figure 21. Parameters defining the state of the robotic system ... 38
Figure 22. ROS topics defining the state of the robotic system ... 39
Figure 23. Structure of the commanding velocity topic[22] ... 40
Figure 24. Components of the MRS-ROS Adapter ... 42
Figure 25. Components of MOCUP implementation ... 45
Figure 26. Prototype of formatted MOPS string[12] ... 45
Figure 27. GAZEBO Simulator with camera feed ... 57
Figure 28. Multiple asset infrastructure ... 60
8
Acronyms
API Application Programming Interface BP Bundle Protocol
CCSDS Consultative Committee for Space Data Systems DTN Delay Tolerant Network
EGP European Ground Prototype EID Endpoint ID
ESA European Space Agency
ESOC European Space Operations Centre FPS Frames Per Second
GPS Global Positioning System GUI Graphical User Interface IMU Inertial Measurement Unit ION Interplanetary Overlay Network IP Internet Protocol
ISS International Space Station LTS Long Term Support
M&C Monitoring and Control MCC Mission Control Centre MCS Mission Control System MAL Message Abstraction Layer
METERON Multipurpose End-To-End Robotics Operations Network MMI Man Machine Interface
9
MOCUP METERON Operations and Communications Prototype MOE METERON Operational Environment
MOPS METERON Operations Software MRS METERON Robotic Services OOP Object-Oriented Programming OS Operating System
RCS Robot Control System ROS Robot Operating System
SCOS Satellite Control and Operation System SDR Simple Data Recorder
SOAP Simple Object Access Protocol SPR Software Problem Report
TC Telecommand
TCP Transmission Control Protocol
TM Telemetry
UDP User Datagram Protocol
URDF Unified Robot Description Format USB Universal Serial Bus
10
1. Introduction
The work presented in this thesis has been conducted during a six-month internship at the European Space Operations Centre (ESOC) from the European Space Agency (ESA) in Darmstadt. Therefore, all the material researched, produced and validated belongs to ESOC, ESA. Most of the work consisted of software development, thus, the source code, the hardware used and test results are propriety of the Centre, and more specifically, of the Ground Data Systems Department. For the making of this thesis, only unclassified documentation has been used. In order to provide a clear explanation of the infrastructure and the relevant components that have been developed, detailed diagrams have been included. These diagrams along with supplementary explanations shall suffice for the understanding of the topics at hand.
The following development has been performed under the framework of the METERON Project. In brief lines, this project aims to design, integrate and test all the required infrastructure to enable planetary exploration in the future. It includes the development of multiple entities involved in the process and the fulfillment of all the requirements to successfully carry out a scientific exploration. As it will be explained later, the project aims to perform these exploratory missions by establishing a joint collaboration between astronauts and robotic systems. Note that the project tries to cover a massively broad field and the development of most of its components has been ongoing for several years already.
1.1 Objectives
The main goal of my contribution to the METERON project is to develop the core structure of a software adaptive layer between the Main Control System and ROS-based robotic systems to establish monitoring and control capabilities. This work included three different development stages: design, production, and validation of this software. These stages are also visible in the thesis layout. Chapter 4 focuses on the design of the components, chapter 5 and 6 serve as a summary of the production phase and chapter 7 shows the multiple tests performed afterwards. Although the final goal is to have a generic adaptation layer, for the testing and validation phase, a specific development had to be conducted in order to test the generic layer into the available robotic asset: the MOCUP rover.
1.2 Requirements
Since this thesis work was performed as part of METERON infrastructure, it had to meet all the relevant requirements established for the project. Due to these requirements, the adaptive layer had to be generic, extendable, efficient and clear.
11
common adapter that can be used by any robotic system to connect to the already developed control system. Second, it had to be extendable so that the core structure of the component can be extended in the future, if new requirements or new components are introduced in the project. Third, it had to be efficient to allow its implementation in light distributions (like ARM operating systems [1]) without requiring too many resources. Finally, the source code had to be
clear as it will be used in collaborations with other centers of ESA and other agencies. This
meant following coding conventions and documenting in detail every part of the development.
1.3 Structure
Although the main focus of the thesis was put into this software connector, several additional components have been developed as well. These components have been created to support and/or extend the generic adapter. Nevertheless, the details of these components have been also included in the thesis.
12
2. Relevant projects
2.1 METERON Project 2.1.1 Overview
The Multipurpose End-To-End Robotics Operations Network (METERON) Project[2] is a European Space Agency initiative in collaboration with other space agencies around the globe. The project aims for the preparation and development of infrastructure for future robotic exploration missions by analysing new technologies and concepts. It focuses on the development of communications, operations, and robotics to be used in these future missions. In order to allow interoperability across other space agencies, the project had to include the development of standardized telerobotic service interfaces. These standardised services were developed by the CCSDS Telerobotic working group and they are able to abstract the proprietary interfaces of each robotic system from the communication protocol [3].
The development of this project includes the production of a set of tools and components, such as the METERON Robotic Services (MRS), the METERON Operations Software (MOPS) or the METERON Operational Environment (MOE), which were developed following the service oriented design principles of the CCSDS Mission Operations framework. An explicit description of these tools has been included further down this document since they are key components of the integration done for this thesis.
The project focused on three different areas of study for these future missions: communications, operations, and robotics. Regarding the communications, the project included a research on disruption tolerance, distance delays, and multiple asset communications. Experiments about the suitability of the Delay Tolerant Network were conducted along with the research. Ultimately, a DTN communication link (based on the Bundle Protocol of ION software[4]) was developed as a communication layer for telerobotic operations in future missions. This DTN communication shall comprise one of the two communication routes between the entities of the infrastructure (the other one being TCP). More information about DTN communication can be found in the chapter 3.6. In terms of
operations, the project focused on the investigation of human-robotic concepts of operations,
13
2.1.2 Possible scenarios
One of the main goals of the project was to define the possible mission scenarios for the exploration missions on a foreign planet. The definition of the scenario comprised all the components involved and the communication links in between them. The most common scenario was defined as follows.
Figure 1. METERON's Infrastructure basic scenario
The previous diagram represents the simplest scenario where only three components are considered. On Earth, there are several Mission Control Centres (MCC) that communicate with each other and use the ground stations around the world to communicate with the remote components. In the whereabouts of the foreign planet, an orbiter around the planet to relay communications and enable a fast commanding route with the assets on the foreign planet’s surface. These robotic assets comprise the third component of the diagram and will conduct the exploration missions along with the astronauts on the planet’s surface.
14
foreign planet. The relay connection was designed as a Delay-Tolerant Networking (DTN) connection where a Bundle Protocol (BP) has been added to the connection for additional security. The details of the DTN connection have been included in chapter 3.
The project also contemplates the scenario where a habitat or a base has been established on the foreign planet. This habitat would act as a nearby MCC with all the tools needed to communicate with the robotic assets and the orbiter. Consequently, another two links would be introduced into the infrastructure. In the following figure, two types of links are represented: direct links (red) and relay links (blue).
Figure 2. METERON's Infrastructure with hub in foreign planet
In this case, the direct link would be the fastest option to communicate with the robotic assets; although communication through the orbiter would also be enabled for special situations (e.g. losing line of sight from the robotic asset or meteorological conditions jeopardising the direct communication).
2.1.3 Validation
15
Figure 3. Rovers used for validation: MOCUP (left) and EGP (right)[3]
2.2 MARVIN Project 2.2.1 Overview
This project is a continuation of the METERON Project and aims to study rover-assisted crew operations for future space missions. In some aspects, the requirements are not fully established yet due to the novelty of the project. The research focuses on evaluating and comparing different ways of executing joint astronaut-rover operations to determine the optimal configuration for these activities[7]. This evaluation includes the division of tasks between the astronaut and the robotic assets, as well as defining the most suitable candidate to control these robotic assets while the activities are taking place. The study also tries to establish the appropriate communication links and the Graphical User Interfaces (GUI) or Man-Machine Interfaces (MMI) to control and manipulate the robotic assets. The experiments in the development of the project focus on task completion, simplification of astronauts’ activities and definition of an accurately simulated environment. This simulated environment could potentially be used for astronaut training before the exploration missions take place.
2.2.2 Possible scenarios
16
Figure 4. Overview of operations scenario[7]
1. Move of crew and rover from habitat to work site
2. Rover assists in crew operations (e.g. light provision, tool handling, video feed…) 3. Rover performs remote operations (e.g. fetching components, mapping…) 4. Crew and rover return to habitat using the rover to transport cargo
Due to the recentness of the project, the modes of operation, infrastructure setup and some other details are still being considered.
2.2.3 Validation
For the validation, the testing site has been defined in the European Astronaut Centre (EAC) in Cologne while the MCC has been located in the European Space Operations Centre (ESOC) in Darmstadt. This setup has been purposely designed to resemble the future application of these tools in real scenarios where the control site is far away from the exploring site. Therefore, EAC is treated as the foreign planet to explore while ESOC is considered the control center and ground station on Earth.
17
Figure 5. JACKAL rover by Clearpath Robotics[8]
The chosen rover is ROS-based and includes a standard internal PC, basic IMU and GPS [8]. From the original design, a mechanical arm and a movable camera have been added for additional functionality. More extras might be added in the near future. The current configuration of the rover can be understood from the following model.
Figure 6. Model of current configuration of the JACKAL rover[9]
18
19
3. Theoretical background
The METERON Project included the development of specific software tools to fulfill the requirements and to carry out the tasks defined in the possible scenarios. From the preliminary scenario shown in Figure 1. METERON's Infrastructure basic scenario, each component acting as a robotic commanding entity required a dedicated software development. In the case of the Mission Control System (MCS) on Earth, the METERON Operational Environment (MOE) was developed. For the orbiter platform, the METERON Operations Software (MOPS) was designed as an in-flight lightweight tool for commanding robotic assets. The communication between MOE and MOPS, as well as the communication between MOE and the rover (direct link), is performed using the METERON Robotic Services. The relation between all these components can be simplified in the following diagram. A detailed explanation of each component of the infrastructure has been included below.
Figure 8. Software representation of METERON's infrastructure
3.1 METERON Operational Environment
20
provides the overall status of the METERON infrastructure and the execution status of all the experiments. The capabilities of MOE include:
Tracking the status of the executed commands as they are forwarded across the different components of the METERON infrastructure
Receiving telemetry from all robotics assets via both links: direct link and relay link (forwarded by the orbiter)
Receiving telemetry related to the status of the METERON DTN network health
Receiving housekeeping telemetry from the different components of the METERON infrastructure
Displaying a map view of the assets’ positions, past traversed path and planned waypoints
Managing file directories and transfers across all the components Visualizing images obtained from the robotic assets
Archiving and retrieval of data from all operations Streaming of video coming from the robotic assets
MOE also acts as a commanding manager that grants permission to different entities for the control of the robotic assets. Moreover, it contemplates the possibility of having several MOE deployments where each deployment has a consolidated and consistent set of telemetry data and is aware of the state of operations performed from the other deployments. Therefore, the permission-granting of commanding authority must be performed in an unambiguous way which has been considered in the design of the Authorization Service. A detailed explanation of the services has been included in section 3.3. The system is composed of a core processing software and a collection of models and plugins that comprise the MMI layout. The system uses the SIMSAT infrastructure as the run-time environment and as the framework.
21
Figure 9. Commanding view of MOE
Figure 10. Monitoring view of MOE
3.2 METERON Operations Software
22
The data unit used in the MOPS protocol is a message. It was kept in a human readable format to facilitate the testing and validation of the communication links. However, this might be replaced with a more sophisticated protocol in the future.
Figure 11. GUI of METERON Operations Software
The METERON Operations Software was used during the completion of this thesis for the integration done with the rover MOCUP (chapter 6).
3.3 METERON Robotic Services
23
The MRS has a service oriented design based on the CCSDS MO framework and the services are specified complying with a reference service model, called MAL (Message Abstraction Layer), which uses an abstract service description language. Information about the MAL can be found in the Blue Book CCSDS Standards [13]. For each deployment, the MAL is then bound to a specific software implementation and communication technology. This is done for both, the application layer and the transport layer, by using standardised interfaces in form of Application Programming Interfaces (API) [3]. This layered architecture can be observed in the following diagram.
Figure 12. Layered architecture of MO framework[3]
24
Figure 13. Connections of MRS Deployment[14]
The interfaces for all the services that comprise the MRS have been included below. A detailed explanation of each service and all the methods can be found in the MRS API document [14].
MRS Interface (Service Layer): provides methods to retrieve the interface of all the other services implemented by the MRS.
Notification Interface (Notification Service): provides methods to send notifications to the service layer for later broadcast to the service layer clients.
Parameter Interface (Monitoring Service): provides methods to publish new values of the monitoring parameters and the subscription and unsubscription of these.
File Transfer Interface (File Transfer Service): provides methods for performing file-transfer related operations.
Action Interface (Action Service): provides the method for requesting the execution of encapsulated operations. It allows the definition of new operations not contemplated in the existing service interfaces.
Camera Interface (Camera Service): provides methods for camera related operations (take images, set camera angles…).
File Management Interface (File Management Service): provides methods for file-management related operations.
25
Plan Interface (Plan Service): provides methods for the planning of robotic assets.
Motion Control Interface (Robotic Motion Control Service): provides methods for motion control of robotic assets.
Status Interface (Status Service): provides methods for status related operations.
Monitoring Client Interface (Monitoring Client): provides methods to obtain monitoring information from other robotic assets.
Notification Client Interface (Notification Client): provides methods to obtain notifications from other robotic assets.
As previously mentioned the C++ API of the METERON Robotic Services has been used for the development of the adapter in which this thesis is based on. Further information about this implementation is provided in section 5.
3.4 Robot Operating System
The MARVIN Project introduced a rover which uses the Robot Operating System (ROS) framework to operate. This is a flexible framework for robotic software integration. This platform aims to simplify the task of creating a fully functional robot system with robust behaviour across a wide variety of robotic platforms [15].
Since its foundation, the ROS platform aimed to encourage collaboration in robotic projects. It has a large community with active forums to answer questions and solve technical problems. It also has a substantial library of open source modules available to every user. This framework comprises a message transport layer or “plumbing”, a variety of tools (for visualization, navigation, control…), a wide range of capabilities and a sharing community. Furthermore, its open source policy imposes the production of quality software since the components may be reused in the future. At the same time, popular components become widely tested by other users who can report bugs to the development team. This communication between users and developers contributes to the software overall robustness.
26
ROS framework is designed to simplify the development of robotic software by splitting the system in simple nodes that interact with each other using a dedicated bus. These nodes or modules guide the development into a modular architecture which is beneficial as it allows module reusability and improves the software readability.
The communication layer between the nodes is performed via a dedicated bus populated by ROS topics. The layer supports TCP and UDP for message transportation. The topics have anonymous publish/subscribe semantics which decouples the information production and consumption. A client/service architecture is also available, but it has not been used for the development of this thesis. These topics are accessed and manipulated by the nodes. The nodes are intended to operate at a fine-grained scale: a complex process would usually require the use of several different nodes with small individual contributions to ultimately complete the task.
This type of architecture provides several benefits to the overall system, as it is explained in the ROS documentation site[16]. The program has an inherited fault tolerance as crashes are isolated to individual nodes. This architecture also reduces the code complexity likely to find in monolithic systems. Finally, the modularity of the system facilitates new implementation or updates.
The project at hand was developed having in mind the advantages of the ROS framework, making use of the ROS bus and dividing the software into modules to simplify the designing process and improve software readability. The adapters built for the completion of this thesis have been implemented as ROS packages.
3.5 GAZEBO Simulator
27
Figure 15. GAZEBO simulation of JACKAL rover
The GAZEBO simulator allows to rapidly test algorithms, design robots, perform regression testing or train AI system using realistic scenarios [17]. The models are defined using URDF files where all the needed parameters are considered to make the object physically realistic. Then, GAZEBO is used as a physics engine to generate the interactions between all the objects and to provide a graphical interface of the simulated world.
3.6 Interplanetary Overlay Network 3.6.1 Overview
The Interplanetary Overlay Network (ION) is an implementation of the Delay-Tolerant Networking architecture’s Bundle Protocol. It has been designed to facilitate the insertion of DTN functionality into embedded systems. At the same time, it aims to reduce the risk and cost of interplanetary communications by simplifying the constructions and operation of automated digital data communication networks [18][4].
28
3.6.2 Features
ION aims to enable delay-tolerant network communications in interplanetary missions by resolving the additional constraints that arise from not having a terrestrial communication. The design of ION focuses on three essential characteristics to address the space-related constrains. First, it achieves efficient bandwidth utilization which is a necessary feature since all the communications between spacecraft and mission control center are wireless and generally slow. Moreover, the spacecraft’s mission usually involves returning a large volume of scientific data so the communication links need to be bandwidth-efficient. Second, it is highly robust as it is a mandatory requirement for all the flight software of the spacecraft. Additionally, in order to avoid inappropriate memory allocations or faulty behaviour, a dynamic memory allocation approach is avoided. Therefore, ION has been designed to use blocks of memory statically pre-allocated at boot time. Last, the Bundle Protocol procedures of ION is computationally efficient in execution. Aside from obvious reasons for having computational efficiency, flight computers must be radiation-hardened for proper operation in interplanetary space and radiation hardened processors tend to be significantly slower. Consequently, computational efficiency is of the highest priority[4].
In addition to the main features, ION provides extra perks, such as an Asynchronous Management Protocol to send messages during a defined period of time and at a given interval. This can be used in the future to simulate a real operation scenario where the orbiter is not visible during an eclipse period.
All these capabilities have been integrated into ION software while following the protocols established by the Consultative Committee for Space Data Systems (CCSDS).
3.6.3 Bundle Protocol
For this project, only one component of the ION software has been required. The bundle protocol (BP) package has been used for the communication of the relay link of the MOCUP implementation (from MOE to MOPS and MOPS to MOCUP). This package supports the following capabilities:
Prioritization of data flows
Bundle reassembly from fragments Flexible status reporting
Custody transfer
Rate control for congestion forecasting and avoidance
29
30
4. Development
4.1 Overview
The METERON project aims to implement a complete infrastructure to be used for future exploration missions. However, the development of the whole framework is vast and complex. Therefore, the goal of this thesis focuses on building one of the many components that comprise the infrastructure: the communication link between any ROS-based robotic asset and the METERON Operational Environment (MOE).
As it was explained before, MOE acts as the mission control system (MCS) of the whole infrastructure and facilitates the control of all the robotic assets. It can also handle other control systems inside the METERON infrastructure. For instance, it is able to connect to the dedicated rover control system (RCS) to be deployed in an orbiter around the foreign planet. This program was designed to be a lightweight controller of robotic assets. It is a necessary entity for the deployment of the relay link. Although this relay link was not the focus of the thesis, its integration in the infrastructure will be included in the future. In this case, the communication between the RCS and the rover should also be developed.
Even though the efforts were put into the direct link, additional development was done for the implementation of the relay link for a specific working rover (MOCUP). This integration helped in the testing phase and the validation of the adapter.
4.2 Software architecture
The adapter had to permit the communication to any ROS-based robotic system. As it was explained previously ROS nodes are independent tools that communicate with each other using the ROS bus. By implementing the code as ROS packages, the modularity and flexibility of the software are guaranteed.
31
Figure 16. Required adapters for direct and relay links
4.2.1 Generic implementation
The first implementation performed for the completion of this thesis focused on the direct link, this is, the development of the MOE Adapter. As it aims to establish M&C capabilities with a wide variety of ROS-based systems, it had to be generic. Therefore, it was called the generic
implementation. From one side, it had to communicate using the robotic services (MRS) with
the mission control system (MOE) and from the other side, it had to communicate using ROS because the rover was ROS-based. Since the adapter had to speak MRS and ROS, it was named MRS-ROS Adapter.
Figure 17. MRS-ROS Adapter
4.2.2 MOCUP Implementation
32
production of additional packages. This whole development has been called MOCUP
implementation. This rover is string-based instead of ROS-based and performs all the
controlling activities inside the NXT from LEGO Mindstorms. Therefore, the first new package (NXT-ROS Adapter) was designed to translate the string-based telemetry into the ROS bus. Once the data was published in the corresponding ROS topics, the MRS-ROS Adapter was able to receive and forward MOCUP’s telemetry to the MCS. For telecommanding, a plugin had to be developed in the MRS-ROS Adapter to translate the commands coming from the MRS into string-based commands that MOCUP was able to understand.
The benefit of this additional development was that the relay link was established with minor integration required. This is due to MOPS being able to communicate using the same string format as MOCUP (as they were purposely developed to interact with each other). By creating a message forwarder node (MOPS-ROS Adapter) able to transmit messages using ION’s Bundle Protocol, the DTN communication between MOPS and MOCUP was achieved. The following diagram illustrates the software architecture for the MOCUP rover specifically.
Figure 18. Additional components for MOCUP's implementation
4.3 Software language
Having opted for an integration based on ROS packages, the choice of the software language was limited. There were two main requirements to consider:
33
Interface provided for robotic services implementation: MRS API provides interfaces in two different languages: Java and C++.
Due to the common ground of both requirements, C++ was selected for the implementation. A different language could have been used, but it would have required the development of code wrappers to work.
On the next chapters, software terminology will be used in order to describe the functionality of the implementations. It is necessary to explain that both implementations have a common structure which will be mentioned throughout the explanation. The implementations have been divided into smaller packages. These packages have a unique role inside its implementation. All of them allow communication between two distinct entities and can be considered as adaptive layers between these entities. The packages are split further into components which also have a unique role within the package. When the functionality of these components is explained, their capabilities are usually referred as methods or functions. These methods referred to a specific procedure associated to an object and they are commonly used in object oriented programming. These basic concepts are thoroughly explained in the Oracle website[19].
4.4 Development outline
The following chapters contain the details of all packages that were developed. They have been divided into two chapters, the generic integration, and the MOCUP integration. All of the packages that are defined in these chapters include an overview, functionality, internal components which had to be developed to complete the package and the interaction between them.
34
5. Generic implementation
The generic implementation only comprises a single package (MRS-ROS Adapter) that acts as a bridge between the asset and the control system.
5.1 MRS-ROS Adapter 5.1.1 Overview
This package enables the direct link communication between the MCS and any ROS-based robotic system. Since the package will be deployed on the asset side (with one deployment for each robotic system), the adapter has to be self-contained and able to speak ROS with the rover and MRS with MOE. As it was established in the METERON Project structure, the communication between the rover and the rest of the entities in the direct link is done via robotic services. The adapter connects to the ROS-based rover using ROS topics in the ROS bus. In simple terms, the following diagram depicts the most basic connection of the adapter.
Figure 19. MRS-ROS Adapter basics
It is worth mentioning that the adapter is not aware of the rest of the entities of the METERON infrastructure. However, the project contemplates the possibility of having more than one MCS deployments. If this is the case, the adapter is unable to listen to one commanding entity and disregard the others. Therefore, the commanding rights management has to take place prior to the communication with the adapter. For this, an authorization service was designed and deployed in MOE. All the MOE deployments (or MMIs) have a copy of all other commanding entities and which one is entitled to commanding. The control system with the authorization for controlling the asset uses the robotic services (MRS) directly to forward the commands to the adapter via the MRS.
35
deployed. This broker can forward the telemetry and scientific data from the robotic asset to all the entities that subscribe to it. These additional elements have been included in the following diagram.
Figure 20. MRS-ROS Adapter’s communication with METERON's infrastructure
The main goal of this package was to enable communication between the rover and MOE. Since there are plenty of capabilities to be developed, a work outline was established to drive the development. The first objective was to allow the movement of the rover by developing the locomotion system. Once this system was in place, the next objective focused on maintaining a
state of the rover. For this, the status system was developed. Afterwards, the capability to report the rover’s state was developed. This was done by the implementation of the
notification system which forwarded these state updates, as well as, other acknowledgements or issues to the mission control system. Finally, the exploration capabilities were introduced by adding the camera and file management services to generate and transfer the information from the camera.
5.1.2 Package function
The adapter is able to perform the following tasks for commanding: Receive commands incoming as robotic services
Translate commands to ROS-based commands
Forward the commands to the robotic asset considering its state The adapter is able to perform the following tasks for monitoring:
Send back notifications through the MRS when the commands are received, accepted and completed
36
Use the state of the asset as feedback for the controller
Use the parameters that define the state of the asset to push telemetry through the MRS
Store image and video locally to later be sent via the MRS upon request of the control system.
5.1.3 Components
The adapter is comprised of three components which interact with each other: the MRS API, a status component, and a controller component. Broadly speaking, the MRS communicates with external entities, the status component keeps an updated state of the asset and the controller component translates the robotic services to ROS-based commands and issues these to the asset considering its state.
MRS API
The MRS API requires the initialization of a Service Layer when the adapter is started. This initialization requests a layout of the available services to get or to register. From here, the adapter can get the Notification, Monitoring and File Transfer services from the MRS. These services are used to send information (notifications, files, and telemetry respectively) back through the MRS. From the Service Layer deployment, multiple services can be registered. The first objective was to develop the locomotion aspect, allowing the rover to move using commands from the MCS. Therefore, during the first stages of the adapter, only the Robotic Motion and Control service was implemented. This service allowed for simple movement commanding of the robotic system. Afterwards, the objective was extended to include services regarding the state of the rover, the notification route to the MCS, the video feed of the camera and the file management of the onboard file store. This objective led to the implementation of the Status Service, Camera Service, File Service and the Action service. A detailed explanation of these services has been included below. For more information about the API, refer to the documentation [14].
The Service Layer enables getter methods for Notification, Monitoring, and File Transfer services and provides the registration methods for the rest of the services.
37
The Monitoring Service provides three methods, subscription and un-subscription of robotic assets (not used in the robotic system side) and a method to publish monitoring parameters which is used to push telemetry back to the MCS.
The File Transfer Services enables a method to retrieve files from a folder which is being monitored by the MRS. Upon request, the contents of this folder are forwarded to the control system.
The Robotic Motion and Control Service provides a wide variety of methods to issue locomotion commands to the asset. Some methods are setters for speeds and other parameters and the rest of methods provide all the motion commands to manoeuvre and control the asset. For an extended explanation of each method, refer to the documentation [14].
The Status Service allows setting a status interval which determines the rate at which the information is sent back to the MRS (e.g. telemetry).
The Camera Service enables multiple camera related methods, such as, capture image or movement commands to set camera angles and the rotation speed of the camera. The File Service provides a method to be called when a new file is stored in the asset.
This command is issued to through the MRS so that the MCS are aware of the new file. The Action Service enables a single method to pass a command as a string. This service
is used when services not yet defined are needed. For the time being, it was used to implement a video forwarding command to toggle on and off the transmission of video over the robotic services.
The configuration of this services, as well as the endpoints for a specific robotic system, are enclosed in a properties file. This file must be configured before the initialization of the software and contains crucial information for the usage of the robotic services, such as, endpoints of each service, path of file storage directory or UDP ports of the system to which the asset is listening to (this last one allows real time video forwarding from any source as long as the stream is broadcasted to the configured port).
Status Component
38
Parameter Definition
POS_X Current position X
POS_Y Current position Y
POS_Z Current position Z
HEAD Current heading
TRAVEL_SPEED Maximum linear speed
ROTATE_SPEED Maximum angular speed
CURRENT_TRAVEL_SPEED Current linear speed
CURRENT_ROTATE_SPEED Current angular speed
BATERY_VOLTAGE Current battery voltage
CAM_PAN Current pan angle of the camera
CAM_TILT Current tilt angle of the camera
CAM_ROTATE_SPEED Maximum angular speed of the camera
Figure 21. Parameters defining the state of the robotic system
As it was explained before, the software has been implemented as a ROS node. The ROS infrastructure that was used in this project is a publisher/subscriber architecture which is one of the two options when using ROS communication (the other one being service/client architecture). This type of architecture was used following the definition of the GAZEBO simulator which was used to test this package. The information provided by the simulator is injected into the bus by the use of ROS topics. These topics act as channels (or named buses) where publishers deposit the information and subscribers are able to obtain it. They have anonymous publish/subscribe semantics, which decouples the production of information from its consumption[20]. In order to subscribe to a topic, it is necessary to know two things about it: Name: the topic is identified by a name. This name is used to initialize the subscription
to the topic.
Type: the type of the topic defines the structure (or container) used by the data on that specific topic. Data can be published in different shapes and forms: single float, array of strings, images, point clouds… It is necessary for the subscriber to know the type of the data to be aware of the structure in which the data has been stored so that the data can be extracted accordingly.
39
The names of the topics are defined by the publisher when they publish in the topic for the first time, opening the channel. Since these names are subject to vary, they have been made configurable through a configuration file. Since the package is deployed as a ROS package, the nodes can be initialized by a launch file which can also provide the values of the configuration at runtime. Therefore, this launch file was used as the configuration file of the package.
Note that the ROS topics allow for multiple publishers and once the connection to a topic has been made between them, ROS is able to skip the serialize/deserialize step (potentially saving a large amount of processing and latency)[21]. The communication between publishers and subscribers work by the use of queueing and callbacks. Whenever the publisher has new information to push into the topic, a new entry is created and pushed onto a queue. The size of this queue is configurable and when the limit is reached, the oldest entries are dropped to store the new ones. From the subscriber side, a callback has to be defined. This function is invoked whenever a new entry populates the topic and it is usually used to withdraw the relevant information to the subscriber. For more information about publishing and subscribing, please refer to ROS webpage [21]. The next figure shows the names and types of the ROS topics used in the status component to obtain the state of the robotic asset. These types enforce a data structure on the topic, so that publishers and subscribers are able to understand each other.
Topic Type
Odometry nav_msgs::Odometry
Battery state sensor_msgs::BatteryState
Camera information std_msgs::Float64
Camera angular speed std_msgs::Float64
Images sensor_msgs::ImageConstPtr
Figure 22. ROS topics defining the state of the robotic system
40
well. Therefore, an increase in accuracy of the localization automatically translates to an increase of performance of the asset.
Controller component
The last component that comprises the MRS-ROS adapter is the controller. The controller has the task of managing the commands coming from the MRS, translating them to a command that a ROS system can understand and, at the same time, considering the information coming from the status component as feedback.
In terms of locomotion commands, there are different ways to control a ROS-based robotic system. It is possible to enable a low-level commanding scheme where the user is able to exactly define how each part/motor/component of the system should behave when a motion command is issued. However, this part of the development is usually performed by the manufacturer if the asset is not homemade. In our case, Clearpath had already developed and tested this part of the controller. At a higher level, ROS-based rovers are usually controlled by publishing the commands on a specific topic. The topic allows to input six different components: three linear velocities and three angular velocities. This has been made as generic as possible in order to allow any robotic system to be fully commanded in any direction (linearly and angularly). The structure of this topic has been included below.
Figure 23. Structure of the commanding velocity topic[22]
41
In our case, the testing asset was a four-wheel rover so only the linear X velocity and angular Z velocities were used for commanding. Therefore, the controller had to be able to translate any locomotion command into entries of linear and angular velocities in the commanding topic. These commands had to be published on the topic periodically in order to operate the rover. Since the state of the rover was also available (provided by the status component), a feedback loop was implemented to perform the motion commands. This feedback loop allows for accurate motion commands as it is the only loop involved in the rover’s locomotion. At a lower level, the linear and angular velocities from the commands are translated into voltage differentials to apply in the wheel motors for a certain period without a feedback process. The error between the desired final position and the current position of the rover was calculated for every iteration of the feedback loop. Additionally, the commanding message was also published for every iteration of the loop to keep the rover moving. The initial stages of the development integrated a simple controller for the locomotion commands where the rover would turn towards the desired location and then, drive in a straight line until the destination was reached. For future development, a more complex integration can be made where the rover selects the optimal path based on information from other sensors avoiding obstacles or risky locations using a navigation tool. Some tests were performed with an open source tool[23] but it was not integrated at these early stages of the development. At the moment, only locomotion through control commands has been contemplated. No autonomous locomotion or navigation has been included for the current stage of development.
Besides the locomotion commands, the controller is also in charge of the handling the following methods:
Getters for parameters that define the system’s state (e.g. pose parameters) Priority commands (e.g. immediate stop command)
Commands for camera operation (e.g. camera orientation and image storing) Setters for velocities and other parameters (e.g. position compensators) Setter of the length of the data forwarding interval
Interpreting commands send as strings via the Action Service (e.g. video forwarding command)
Interaction between components
42
Figure 24. Components of the MRS-ROS Adapter
As it can be observed, the controller is the keystone of the node. It handles the updated information coming from the status component and interprets the commands coming from the robotic services. The status component only focuses on keeping an updated state of the rover by receiving the updates in the ROS callbacks and forwarding them to the controller and the monitoring service. The MRS provides an interface where the commands coming from the controlling system invoke methods that at the same time are able to issue public commands from the controller.
If we take a look at the overall picture, the MRS-ROS Adapter can be integrated into any robotic system that provides ROS communication. It does not interfere with the definition of the robotic system as it only uses the command velocity topic to connect to the low-level layer. This allows for other commanding methods to also control the asset, such as a different MCS or a direct Ackermann control with a joystick or an RC controller. In our specific case, this adapter is planned to be one (direct link) of the two control links that the asset will ultimately have. For testing purposes, a GAZEBO simulated rover was used. The software architecture of the simulator would be quite similar to the architecture of a real case scenario.
43
44
6. MOCUP Implementation
The MOCUP integration is comprised of all the components that produce a ROS-based connection to the MOCUP rover. Additional development had to be made from the generic integration because the rover was not ROS compatible in the first place. If the rover had been ROS-based, no extra development would have been needed, only adjustments in the configuration files. The main goal of this development was to create a testing framework with a physical rover for the previously explained generic implementation. Prior to this development, all the testing was performed in a simulated environment (GAZEBO).
The MOCUP rover has been configured to receive commands in a very specific way, as it is explained in the following section. Therefore, new adaptive layers had to be developed to establish the two communication links (direct link and relay link). Note that the relay link has not been developed for the generic integration yet. However, in the specific case of MOCUP, the rover and the rover control system (MOPS) are able to understand each other as they have the same string format communication, so a simple note forwarding the message was enough to establish this link. The three packages that are part of the MOCUP integration are the following:
NXT-ROS Adapter: this layer establishes the bridge between the NXT and the other two ROS packages. It connects to the NXT via USB and it is also connected to the ROS bus. It receives the messages from the NXT and broadcasts them into the ROS bus. Conversely, it receives messages from ROS and pushes them through the USB connection to the NXT.
Plugin for MRS-ROS Adapter: this extra layer has been added to the generic implementation to translate the commands coming from the MRS into the specific format that MOCUP uses. It (along with the MRS-ROS Adapter) enables the direct link with the MOCUP rover.
MOPS-ROS Adapter: this layer enables the communication with MOPS to establish the relay link. It enables the relay link with the MOCUP rover.
45
Figure 25. Components of MOCUP implementation
Note that the MRS-ROS Adapter and the MOPS-ROS Adapter are completely independent of each other. If for any reason, one of the packages ceases to work, the other communication is still available.
6.1 Plugin for MRS-ROS Adapter 6.1.1 Overview
This package was added to the MRS-ROS Adapter to translate the received commands from the robotic services into MOCUP compliant commands. In order to command MOCUP, the commands have to be forwarded to an NXT Lego Brick. The brick has a proprietary software installed which acts as the controller of the rover. This brick only understands an input in the shape of MOPS formatted string. Therefore, communication via MOPS formatted string is required, despite the inefficiency of the message structure. The MOPS strings look like this:
Figure 26. Prototype of formatted MOPS string[12]
46
integration, the commands had to be formatted so that they look like MOPS commands. All of the string components contains relevant information that needs to be included.
CODE: three-digit hexadecimal code that uniquely identifies each command SOURCE: name of the message source (in our case MOE)
DEST: name of the message destination (in our case NXT)
COMMAND: name of the command (it has to be previously defined in the NXT) INPUTS: comma-separated inputs of the command
OUTPUTS: empty string when the command is sent but it contains the information when the message comes from the rover
RECEIVED: boolean flag that contains “False” until it gets changed to “True” on acknowledgment of the message
EXECUTED: boolean flag that contains “False” but gets changed to “True” on execution of the command
moeinputsid: MOE command identifier (id generated by the MCS)
moeinputscounter: command counter used by MOE for displaying the commands correctly.
The last two fields were introduced to store the extra IDs coming from MOE when the commands were issued following the relay path (MOE to MOPS to MOCUP). In our case, the commands are issued directly from MOE so the adapter already knows these IDs. Aside from these fields, two symbols are also used in the MOPS string. First, the pipe “|” separating the different fields and the hashtag “#” separating different messages.
With the plugin, the commands from the MRS are translated into this type of message and then published into a ROS topic. This topic is read by the NXT-ROS Adapter which establishes the communication to the NXT. At the same time, the plugin has the functionality to interpret the notifications coming from MOCUP. The notifications are received in a MOPS formatted string. The message is then parsed and the RECEIVED and EXECUTED fields are evaluated. The plugin translates them into notifications that can be sent back to MOE using the Notification Service.
6.1.2 Package function
The adapter is able to perform the following tasks for commanding:
Translate the commands from the MRS-ROS Adapter into a MOPS string
Broadcast the string to a ROS bus which is read by the NXT-ROS Adapter later on The adapter is able to perform the following tasks for monitoring:
47
Parse and interpret the notifications so that the MRS-ROS Adapter can send back the appropriate notifications to the MCS
6.1.3 Components
This package contains two components, a library to convert the commands into MOPS strings and vice versa; and a listener to receive the notifications from MOCUP. Both components are added to the MRS-ROS Adapter as plugins. Therefore, the architecture of the final component is identical to the MRS-ROS Adapter.
6.2 NXT-ROS Adapter 6.2.1 Overview
The NXT-ROS Adapter is in charge of the communication between the other packages and the NXT. On the one hand, the package is able to communicate with other ROS nodes by the use of topics in the ROS bus. On the other hand, the package establishes the connection to the corresponding USB port to which the NXT is connected. The USB port is defined by the product and vendor ID of the connected device. These two parameters are configurable from the launch file. The limitation of data traffic from and to the NXT is limited by the hardware. For the testing and validation stages, a Raspberry PI2 was used as a platform where all the components were deployed. However, it is worth noticing that if other USB connections are added to the motherboard, the hardware can get overworked and the application can crash. This has been extensively covered in chapter 7 of testing and validation.
In order to establish USB communication, the libusb library with the libusb-1.0 API was implemented. This is a C library that provides generic access to USB devices. As the web page states, “it is intended to be used by developers to facilitate the production of applications that communications with USB hardware”[26].
48
or notification. If the message is a notification, it is published as a whole because the plugin created for the MRS-ROS Adapter is able to handle it. If the message is telemetry, the message is split into the different components and the updated value of each parameter is published in the appropriate topic of the ROS bus. This way, the status component of the MRS-ROS Adapter is able to obtain the updates via the topic callbacks as it does in the generic implementation.
6.2.2 Package Function
Based on the USB implementation and the ROS framework that has been used during the whole development, this package has different functions depending on the route (or message direction).
The adapter is able to perform the following tasks on the messages going to the NXT: Listen to two ROS topics (one for the direct link and one for the relay link) Push the messages to the NXT using the USB communication
The adapter is able to perform the following tasks on the messages coming from the NXT: Listen to messages from NXT in a USB port
Identify if the message provides a telemetry update or a notification
In case of notification, the message is forwarded via the link used to issue the command in the first place (direct or relay)
In case of telemetry, the message is parsed and all the parameters are published in the appropriate ROS topics so that the MRS-ROS Adapter is able to understand and push to the MCS through the robotic services. The message is also published as a whole in the topic directed to the relay link because MOPS is able to understand these messages and extract the telemetry from them.
6.2.3 Components
The package contains two main components. The communication component which allows the connection to the NXT and the message processor which handles the messages.
USB component
This component handles the USB communication. It contains four methods:
49
USB ending method: contrarily to the starting method, it releases the interface and closes the device. Needless to say, this method is called when the node is stopped. USB writing method: it performs a bulk transfer of data to the connected device. The
data is introduced as a string.
USB reading method: it performs a bulk transfer of data from the connected device if available. The data is copied into a string for later handling.
Message processing component
This component handles the messages obtained from the NXT, as well as the incoming messages from the ROS topics of the direct and relay links. Regardless of the source (NXT, MOPS or MOE), the component follows the same steps. First, it checks that the message is a MOPS formatted message. After this check, the message is split into the different fields and the message is accepted. Finally, the source and destination of the message are checked and the required action is executed according to the explanation given at the beginning of this chapter.
Interaction between components
Most of the activity of this node is processed by the message processing component. It receives all the messages coming from ROS and the NXT (provided by the USB component) and handles them. According to the message, it is forwarded to the other two adapters (MRS-ROS Adapter and MOPS-ROS Adapter) via ROS or to the NXT using the USB component.
6.3 MOPS-ROS Adapter 6.3.1 Overview
50
simple interface for the operation of robotic assets while fulfilling the requirement of being lightweight.
In later stages of the development of the METERON project, the settlement of a ground station on the foreign planet was also contemplated. This hub would have a deployment of the mission control system (MOE) to monitor and control all the parts of the infrastructure. In this case, the orbiter can also act as a relay entity for the communications within the planet. This could be useful when the communication between the hub and the robotic system is interfered due to:
Atmospheric phenomena Lost line of sight
Direct link is highly populated by other processes
The relay link opts for a DTN communication protocol. For this, the Bundle Protocol (BP) from the ION package used. A detailed explanation of this protocol can be found in section 3.6. In simple terms, the protocol requires the division of the messages in small packages (bundles) which are sent from an endpoint (EID) at origin to another EID at the destination. The messages are reassembled from the bundles upon reception. This ensures a connection where the data is not lost even if there are instabilities in the connection. For the generic implementation, this connection has not been established yet. Since it would require the translation from formatted-string commands to ROS compatible commands. However, for the MOCUP implementation, this link is easily established since the rover and MOPS are able to communicate with each other. Therefore, the connection was achieved by establishing a simple ROS package to forward the messages between the two entities (MOCUP and MOPS) using the ION’s Bundle Protocol.
6.3.2 Package Function
The functions of this package are quite straightforward. If the messages are coming from MOCUP and going to MOPS (e.g. telemetry updates or notifications):
Listen to the messages coming from NXT via ROS (these messages were published by NXT-ROS Adapter)
Build the packets by implementing Bundle Protocol over messages Forward the bundles to EID in MOPS
If the messages are coming from MOPS to MOCUP (e.g. commands): Listen to the bundles from MOPS at a dedicated EID
Assemble the messages from the bundles
51
6.3.3 Components
For simplicity, a single component has been developed to performing all the previous tasks and thus comprising the MOPS-ROS Adapter package. The component has four different methods:
Bundle protocol initialization method: this method performs all the required steps to open the DTN communication. First, it attaches a session of the bundle protocol and then, it opens the sending and the receiving endpoints. Both endpoints are easily configurable in the launch file.
Bundle protocol closure method: it closes both endpoints and detaches the BP session. This method is called when the node shuts down to ensure safe handling and closure of the endpoints.
52
