demonstrating the feasibility of era operations from...
TRANSCRIPT
Demonstrating the feasibility of ERA Operations from Ground
C.J.M. Heemskerk (1), M. Visser (1), D. Dal Zot (2), J. Gancet (2), F. Wokke (3)
(1) Dutch Space P.O. Box 32070, 2303 DB Leiden, The Netherlands
(2) SAS, Leuvensesteenweg 325 1932 Zaventem, Belgium
(3) NLR, Voorsterweg 31, 8316 PR Marknesse The Netherlands
INTRODUCTION
In the framework of the ESA STEP programme, an industrial team has investigated various extensions to the baseline capabilities of the European Robotic Arm (ERA). The Study Team was led by Dutch Space and included NLR, SAS and Verhaert. The name of the study XEUS In-Orbit Assembly (XIOA) refers to the original target application: The assembly of a giant X-ray mirror for a next generation space telescope at the International Space Station (ISS). Shortly after the study started, the XEUS mission concept was changed, introducing new mirror technology and direct injection into a higher orbit, bypassing the ISS as an in-orbit assembly station. The objectives of the Study were adjusted accordingly, towards more generic extensions of ERA capabilities, increasing ERA s versatility for in-orbit assembly, including the handover of payloads and support the servicing of a free flying exposure facility.
This paper we present one major enhancement to the ERA system: allowing ERA to be controlled from ground. In a separate paper in this conference [1], we describe other enhancements: the design of a new Capture Tool that will allow ERA to capture Free Flying payloads, the derivation of enhanced control settings allowing ERA to move substantially larger payloads, and the design of a new Controlled Docking strategy that will allow ERA to attach a large payload at a standard ISS docking interface.
Figure 1 Testing of the new Ground Control System and On-Board Assistant in the ERA Mission Preparation and Training Facility at ESTEC
In Proceedings of the 9th ESA Workshop on Advanced Space Technologies for Robotics and Automation'ASTRA 2006' ESTEC, Noordwijk, The Netherlands, November 28-30, 2006
The paper discusses the implementation of new functionality in the ERA ground segment and the ERA flight software to allow ERA operations to be commanded from ground. In the study, the team started with an analysis of the key requirements, designed a new system for ground control including the introduction of a new flight element, implemented a prototype of the proposed concept, and successfully tested it in a representative configuration.
KEY REQUIREMENTS
The top level requirements were straightforward:
To reduce crew time involvement in the command and control of ERA for the crew on-board, by shifting some tasks and responsibilities to crew on-ground
To maintain the same level of safety
The potential for any space system operator located on ground, depends to a large extend on the communication facilities available: Contact windows, bandwidth, and round trip communication delays, all have their influence. The current ERA baseline was designed to work with limited ground contact, in line with the communication coverage provided by the Russian ground infrastructure for ISS. According to this coverage, available communication time with ISS is around 5 minutes (350 km high) or 7 minutes (460 km high) at each pass, i.e. 5-7 minutes per 90 minute orbit. During these short windows it may be possible to upload some new ERA programs and initiate fully automatic sequences, but it does not allow an operator on ground to supervise lengthy robotic operations. It was therefore decided for the remainder of the study to assume near continuous coverage via data relay satellites like TDRSS.
The assumed use of TDRSS will provide much better coverage and near continuous visibility. For the bandwidth, no technical problems are expected as TDRSS supports video channels. The remaining challenges are handover gaps, signal outage and communcation delays inherent in using an existing data relay network.
Without proper countermeasures, short interrupts in the communication loop with an operator on ground will be extremely disruptive. In the current baseline, ERA operations are supervised by an operator in-orbit, using either the ERA Internal Man-Machine Interface (IMMI), running on a standard Space Station laptop computer or the ERA External Man-Machine Interface (EMMI), a command panel used during spacewalks. A dedicated safety protocol connects the ERA MMIs and the ERA Control Computer (ECC) in a continuous and explicit exchange of messages confirming the system health status: The MMI-Alive protocol and the ECC-Alive protocol. Event a short loss of communication will initiate a response from one of the Alive checks, and trigger an emergence stop. This in turn will cause large problems in ERA mission continuity. Therefore, a key question in the study became How to cope with short (temporary interruption) or long (actual loss of visibility) loss of communication?
A NEW FLIGHT ELEMENT: ON-BOARD ASSISTANT (OBA)
The proposed solution is the introduction of a new flight element: the On Board Assisitant (OBA). This On-Board Assistant mitigates, to a certain extent, the consequences of communication loss between Ground Control and ERA.
Figure 2 The On Board Assistant (OBA) in operational context
2
Figure 3 The On-Board Assistant concept
In case of communication loss, the OBA behaves according to a well defined policy in order to minimize the impact of communication loss. During the entire period of Ground Control the OBA is the Point Of Control (POC). It runs the alive protocol with the ERA Control Computer similar to the ERA IVA and EVA-MMI.
The ground operator remotely controls the modes of the OBA. In specific modes, the OBA can autonomously trigger relevant commands, according to the ERA execution context: Enabling ERA to proceed with further (safe) actions, or on the contrary, preventing the initiation of or even interrupting the execution of a critical action. A critical action would typically an action that makes ERA move.
The OBA ensures the consistency of data transmitted to the ground when communication is recovered. It improves operator confidence in operating ERA from the Ground. The heart of the OBA is a decision maker. It operates according to a strictly defined mode logic, illustrated in Figure 4.
The nominal mode is M0. In this case the space-ground connection is OK. In this situation, the OBA is passive. The initiative is with the human operator in the GCS. When the space-ground connection is lost, the OBA takes over. Expecting a fast reconnection, the OBA behavior is confident , mode M1. If the connection is lost for a longer time, the OBA mode switches to M2, and the OBA will allow only non-critical actions to continue, and interrupt any ongoing critical actions. When ERA is executing a longer sequence of commands, containing a mixture of non-critical and critical commands, the execution will pause just before the first critical action. Mode 100 is used when the connection is OK, but GCS operator wishes to delegate some autonomous capabilities to the OBA.
Mode
Description M0 Connection is OK. The
OBA has no initiative: every initiative should be performed by human (from the GCS). Nominal mode.
M1 Connection is lost for a short time. Expecting a fast reconnection, the OBA behavior is confident .
M2 Connection is lost for a long time. Only the non-critical actions are continued.
M100
Connection is OK, but GCS Sup. operator wishes to delegate some autonomous capabilities to the OBA.
GCSinterface
ERA TMProcessor
ERA TCProcessor
ExtSimInterface
OBA
OBA Decision Maker
MP
TEG
CS
ERA + OBA TM
ERA + OBA TC
ERA TM
ERA TC
TCP/IP
ExtSim
Internal data flow
M0
M100
M1
M2
[ Com Loss ]
[ Long Com Loss Timeout ]
[ Com Loss ]
[ Com Restored ]
[ Com Restored ]
[ Mode SwitchingRequested ]
[ Mode SwitchingRequested ]
Communication OK
Communication Lost
Figure 4 OBA Mode Logic
3
A prototype of the OBA was developed in C++, as a standalone program. The OBA prototype has no GUI, only console feedback is provided during runtime. The main challenges were to establish a robust remote connection to GCS (allowing disconnection reconnection with limited impact) and to connect to the MPTE with EuroSim via the ExtSim link. A significant effort was spent to dot the i
in reading, analyzing and interpreting ERA TM, and in getting the
OBA to send ERA TC in the right format at the right time.
The OBA concept elegantly handles the challenge of variable communication delays. For safety reasons, command buffering is not an option: each command should be individually and explicitly acknowledged, before next action is allowed to proceed. To maintain synchronisation between the OBA on-board and the GCS on-ground, each activated command is tagged with the date of emission of the command by the operator, and prepared for sending. If it cannot be sent within 1 second after issue (due to some communication issue), the command is dismissed.
GROUND CONTROL STATION
The ERA baseline ground segment already contains some elements that are actively used during ERA operations on-orbit. Together, these elements are known as the On-Line Mission Support system. The main capability of the OLMS is to provide a window on the ERA telemetry, and allow an operator on-ground to monitor the execution on-orbit.
Figure 5 Ground Control Station Architecture
During several MPTE test campaigns it had been shown that one element of the OLMS, the Mission Support IMMI (MS-IMMI), was a good way to keep track of the ERA status. The MS-IMMI is a laptop application closely resembling the IMMI used to control ERA on-board. In the Study, it was decided not to re-invent a new ERA telemetry display, but keep the proven MS-IMMI interface. New functionality in the GCS therefore focussed on the telecommand generation side and the monitoring and control of the OBA status.
The GCS Supervisor was developed in C#. This allowed rapid development of GUI, an easy setup of network services (TCP/IP and UDP connection means, etc.), and efficient event-based features. During the development of the GCS, the main technical challenges were to establish a robust remote connection to OBA (allowing disconnection / reconnection with limited impact), integrating the MS-IMMI in the GCS (setting up the MS-IMMI, transmitting well formatted TM frame) and providing an adapted GUI for monitoring and control.
4
DEMONSTRATION ARCHITECTURE
As part of the Study, a complete demonstration for Ground Control was set-up. Working prototypes of the GCS and OBA were created as described above. The demonstration architecture (Figure 6) involved a test setup with the ERA Mission Preparation and Training Facility (MPTE) at ESTEC playing the role of ERA on ISS. The Ground Control Station was implemented and tested from two locations: One setup using dedicated workstations and the OLMS MS-IMMI at MPTE ESTEC, and a second test setup with the GCS and a copy of the MS-IMMI located at SAS premises in Brussels. To provide a basic video connection capability, a Skype based webcam connection was implemented.
The demonstration was setup to show how a Loss Of Signal (LOS) and other failure situations could be handled in an elegant way. During short communication losses and non-critical operations, the On-Board Assistant should allow the operation to continue autonomously. When execution a longer sequence, autonomous exection should be paused just before a critical function. After the communication link is re-established it should be possible to resume the nominal operation in a straightforward way. When the LOS occurs during a critical function, the program execution should be aborted. After a program abort, similar to recovery from other failures detected by the ECC on-board, some datasets may have to be reloaded after the connection has been restored. In all cases, the entire recovery process could be monitored on and controlled from the Ground Control Station, without the need for on-board crew assistance.
Figure 6 Demonstration architecture
The prototypes of GCS and OBA were tested and behaved as expected. Several major technical issues involved with ground control have been resolved. It was demonstrated that ERA can be controlled from ground in a straight-forward manner. As a result, a significant reduction of crew time can be expected. The concept is based on the introduction of a new flight element, the On Board Assistant to mitigate the effects of communication loss.
There is still some work to be done before the ground control concept can be formally used in the real ERA. E.g. the communication schemes used during the study are not identical to the operational configuration: real links in the MCC-Moscow, including an actual Space-Ground link, and MilBus based communication between OBA and ECC have to be introduced.
DEMONSTRATION SCENARIO
In the study, two different reference scenarios were considered to put the development of new ERA capabilities in a mission context: The XEUS scenario and the WSTF scenario. The XEUS scenario included new tasks like the handover of a large payload from SSRMS to ERA, the placement of a large payload on ISS docking port by ERA and the assembly and inspection of XEUS mirror by ERA. The WSTF scenario was dedicated to the capture of a free flying payload by ERA, and providing ORU exchange services to it.
5
Both scenarios were kinematically analysed using ROBCAD. It was found the new scenarios pose real additional design challenges for the ERA system. Large payloads like the XEUS mirror package are clearly beyond ERA baseline dynamic capabilities. Also the ERA baseline grapple range and targeting approach do not match with the relative motion of large payloads like XEUS or moving payloads like WSTF.
Figure 7 Handover of a large payload from SSRMS to ERA
Figure 8 Moving the large payload to the docking port of the Service Module
Figure 9 Inspection a deployed mirror
6
Figure 10 WSTF scenario: Capture of a free flyer
Figure 11 Capture of the free flyer, perpendicular view
7
CONCLUSION
The paper described and discussed the implementation of new functionality in the ERA ground segment and the ERA flight Software to allow ERA operations to be commanded from ground. A ground control concept based on interactive autonomy appears to provide the best balance between safe operation and crew time saving. The human operator is freed from routine activities, but can always override the robot actions, both from the standard ERA on-board man machine interfaces as well as from the new Ground Control Station.
The system concept was tested in the ERA Mission Preparation and Training Facility (MPTE) at ESTEC, with a remote Ground Control Station located at SAS premises in Brussels. The system was shown to handle Loss Of Signal (LOS) and other failure situations in an elegant way. During short communication losses and non-critical operations, the On-Board Assistant allows the operation to continue autonomously. Autonomous exection is paused before a critical function, and can be resumed without any dataset reloading. When the LOS occurs during a critical function, the program execution is aborted. Similar to recovery from other failures, some datasets have to be reloaded after the connection has been restored. In all cases, the entire recovery process could be monitored on and controlled from the Ground Control Station, without the need for on-board crew assistance.
The proposed ground Control concept does assumes near-continuous coverage, implying some form of data relay is implemented. The most demanding part will be the downlink of supervisory video information. In principle, the Mission Support copy of the ERA Internal man machine Interface (MS-IMMI) provides an adequate view of the telemetry for the ground operator to monitor the progress of ERA. Additional data on the mission in progress and the internal state of the On-Board Assistant is provided on the GCS screen.
With the newly proposed On-Board Assistant (OBA), a new flight element is introduced that can assume the role of an ERA MMI plus the role of an on board operator. The new element is essential to guarantee safety during LOS episodes, and other failures, prevents unnecceasry interrupts of the mission, avoids re-loading of datasets and supports full control from the ground. The OBA may even introduce a new concept of on-board autonomy into the ERA system, and reduce some of the workload of the on-board crew, without using ground control
REFERENCES
[1] C.J.M. Heemskerk, M. Visser, D. Vrancken, Extending ERA s capabilities to capture and transport large payloads , in: Proceedings of the 9th ESA Workshop on Advanced Space Technologies for Robotics and Automation - ASTRA 2006, ESTEC, Noordwijk, The Netherlands, November 2006
8