Figure 4 - uploaded by Jan Thomas Harder
Content may be subject to copyright.
Source publication
The objectives of on-orbit servicing (OOS) missions include manipulation, proximity operations and inspection of target satellites. Therefore the servicer satellite often has to be teleoperated at low latency for several minutes to fulfill these tasks. That means communication plays a crucial role for OOS missions because real time teleoperation in...
Context in source publication
Context 1
... realistic communication scenario under high data rates in the Ka-Band has still to be done. Therefore the big picture of the experiment presented in this paper is to find out, if the round-trip delay from generating data at the spacecraft including transmission via a DRS and displaying the data on ground can be kept below the requested time limits. Furthermore the quality of the data transmission shall be evaluated. For the evaluation of a Ka-Band communication path its round-trip delays and the transmission quality a test environment needs to be implemented where measurements can be performed as close to reality as possible. To reach that goal two projects at the Institute of Astronautics will be brought together: Forrost (Forschungsverbund für Robotische On-Orbit Servicing Technologien) and Racoon-Lab (Real-time Attitude Control and On-Orbit Navigation Laboratory). Forrost is a project funded by the Bavarian Research Foundation and is focused, among other things, on the Ka-band communication link between the spacecraft and the ground station, while the idea of Racoon is to implement a realistic ground based simulator to demonstrate the capabilities of telepresent real time teleoperation for in space operations. In order to perform a realistic measurement of the communication path two important things are required. First the implementation of a realistic high bandwidth communication path with measurement points for the characterization of the transmission delay and second a source for realistic data similar to that of a telepresent servicing scenario. The realistic communication path will be implemented as showed in Fig.2 and is described in chapter 3.1 in detail. In contrast to the real scenario of Fig.1 some simplification are introduced. The communication path demonstrated in this work is focused mainly on the downlink from the spacecraft to the ground station because in that direction the amount of data is much higher than for the uplink [8]. The high amount of data results from the video data created by the onboard cameras. That data needs to be compressed on the spacecraft which can be realized using a new space computer currently in development. Thereafter it is transmitted over a real space link. To prepare the data for transmission over the link channel coding and modulation is done with a standard Ka-Band satellite modem. Since only one Ka-Band modem is available for the experiment, the modem is used to demonstrate both sides of the return link from the spacecraft to the ground station. The transmission section of the modem corresponds to the high frequency system on the servicer satellite while the receiving section corresponds to modem used at the ground station. It is assumed that the space-qualified hardware used later at a servicer satellite for data transmission would have similar features as the transmission section of the ground-based satellite modem used here. The DRS that will mirror the signal will be most likely Hotbird 6. Visualization of the video data for the human operator at the ground station is performed in a simple console using OpenGL. The forward link from the ground station to the servicer satellite is closed over the local network with an artificial delay created by software. Realistic data has to be generated and send over the communication path as it influences for example the image compression and data multiplexing performance and hence the entire round-trip time. This leads to the demand of a realistic orbital simulation environment where data generation can be done as close as possible to a real OOS mission. For this experiment the relative kinematic and environment conditions including lightning between the servicer satellite and the target satellite will be simulated in an OOS test bed on ground in part in software and in part in hardware as described in chapter 3.2. Using the described setup of the communication path the feasibility and quality of the transmission for RTTO is characterized by measuring round trip delays, bit error rates, data rates and jitter depending on different sensor configurations. A detailed measurement description is given in chapter 4. For data acquisition and processing, among other sensors, the ERViS computer [9] is used which is being developed at the moment. Based on work by Diehl GmbH three universities ( Universität Erlangen, Hochschule Hof, Technische Universität München ) are about to upgrade the computer. The goal is to design a real-time data and video processor which is composed of “Commercial-of-the-shelf” (COTS) components. At the end of its development ERViS will contain three independent working CPUs which can be run in redundant operation with high reliability or independent from each other with high performance. In the first case the three CPUs do the same processing and using a voting mechanism to evaluate the quality of the data and in the second case each CPU can process its own data to increase the processing speed (Fig. 4). At the moment three ERViS computers exist which are at Technical Readiness Level 3 (TRL). They were tested successful concerning functionality, stability and interfaces. But nevertheless more redesign is required to reach smaller dimensions of the computer and assure radiation hardness. In the OOS Scenario ERViS will be used to process the video data taken by the onboard cameras. The camera will have a resolution of at least 640x480 pixels, a grey scale of 8bit/pixel and a frame rate of 15 Hz. This leads to an uncompressed data rate of about 40 Mbit/sec which can be reduced by onboard compression to about 5 Mbit/sec. In the future additional data processing tasks such as data multiplexing shall also be added to ERViSs task areas. The downlink path starts with the recording of the data (Fig. 5) from sensors (e.g. camera, haptic sensors, housekeeping data sensors). These data is transmitted to onboard data handler which collects the data from the different sensors and forward these data to the protocol packetizer. After that the data is multiplexed by the data multiplexer into one continuous data stream. Then forward error correction coding is applied by the channel coder to the data stream. The next steps are to modulate, up-convert and transmit the data stream via a data relay satellite. After receiving the data from the DRS the stream runs through the communication path in the other direction until it arrives at the man-machine interface for further processing by the human operator. As depicted in chapter 2, the type of data sent over the link is important as it influences the link performance and must therefore be considered within the link characterization. In order to produce realistic sensor data (foremost video data but also other telemetry) the simulated space environment of Racoon-Lab is used. The Racoon-Lab itself is a ground based on-orbit servicing and space debris removal simulator that is currently in development and will be capable of simulating near-realism on-orbit servicing scenarios in the future. Its design is based on the system architecture of a real space mission and is therefore suitable to simulate scenarios as illustrated in Fig. 1. On the top level it consists of four major parts. First a simulated space segment contains all relevant parts that are exposed to the space environment. These parts are assembled to a simulated spacecraft that combines computer simulated and real space hardware to return realistic responses and sensor information to the human operator. Sensor and actuator stimuli of the simulated spacecraft interact with a simulated space environment. The simulated environment is itself part software and part hardware as needed for the simulated spacecraft. Second a link segment enables realistic communication between the simulated spacecraft and the ground station and is the critical bottleneck limiting data rates and access times. Third a ground segment contains data processing facilities as well as the operator environment where humans can test and evaluate new control concepts for the servicer robot operating in the proximity of the target. Finally a simulation control segment offers many simulation control and analysis tools to identify possible hazards for real missions and reveal new targets for future optimizations. Racoon-Lab is a long time strategy of LRT. Thus results of the Forrost project will later enhance many components within the simulated spacecraft, the link and ground segment. The hardware part of the simulated space environment used for this experiment consists of a dark room to simulate the black space background for cameras and includes in the current configuration two mechanisms to perform planar proximity operations in the orbital plane of the servicer. The mechanisms are a 2D motion table and three degrees of freedom rotation device (Fig.6). The table has a travel distance of 4m by 5m so that close range proximity operations can be simulated. The loading capacity is 100kg which allows even large experiment setups to be carried. The maximum travelling speed is 0.25m/s and above the normal relative velocities reached during proximity operations but could be required in some axis mapping configurations where additional virtual velocities are added. The configuration of the rotation device is suited to simulate the movement of a nutation free spinning target. It will carry a lightweight mockup of the uncooperative target satellite, covered with realistic surfaces. Additional degrees of freedom will be included later, if required for the experiments. All axes are coordinated and driven by a real-time motion controller, so that inputs from the simulated spacecraft or the operator can be mapped immediately to the motion hardware. A 2000W electrical power light source is used to simulate lightning conditions. As stated in chapter 2 the link performance in the given scenario is defined by the four parameters data rate, round trip delay, ...
Citations
Modern high data rate satellite communication systems increasingly utilize the Ka-band due to its ability to support higher bandwidth. Prior research work presented a copper-galvanically produced Ka-band horn array antenna and associated waveguide distribution network, mounted on a two axes mechanical steerable mechanism (LISAMS) for use aboard fast, low earth orbiting satellites. The current project, LISAES, investigates the feasibility of a similar horn array antenna, but fitted with liquid crystal phase shifters in the transmission path of each horn, which now allow steering of the antenna boresight through beam forming without the use of mechanically moving parts.
Upcoming space missions in the fields of on-orbit servicing and space debris removal will face highly complex tasks which require significant increases in complexity and capability of spacecraft systems, as well as increased dexterity of manipulators. In order to provide methods and technologies allowing real-time teleoperation in orbit, the Institute of Astronautics (LRT) at the Technical University Munich (TUM) is researching different technologies that will be needed for this new type of spacecraft mission operations. With the on-orbit servicing scenario as leading example mission, the main focus lies in developing technologies needed for teleoperated close-range proximity operations including inspection and docking maneuvers.
Real-time Tele-operation (RTTO) is a control concept for tasks in which in-situ manipulations by humans are not feasible (e.g. dangerous environmental conditions), and autonomous control is demanding due to complex tasks and unforeseeable problems arising during mission conduct. Possible applications of RTTO in space vary from debris removal, using robotic spacecraft to on-orbit servicing of existing satellites. One key challenge in the design of a RTTO spacecraft is the communication architecture that provides a high data rate, low-latency bi-directional information transfer between the satellite and the human operator. This paper proposes an extended definition of communication architectures. The proposed definition defines not only the orbital positions and main specifications of all elements of a communication link, but among other parameters includes also the required performance of data processing/transfer within the spacecraft and between all relay nodes. Possible orbital constellations of servicer, relay nodes and ground stations are analyzed and network topologies can be evaluated. Subsequently the link performance is investigated measuring achievable data rates, round trip delays and bit error rates in an end-to-end hardware-in-the-loop simulation including a real world space link.