INTRODUCTION

Robotic operations in space with telepresence systems require high data rates for sensor and video feedback in combination with very low delays for precise and transparent control. The ESA funded project HiCLASS-ROS (Highly Compact Laser Communication Systems for Robotic Operations Support) demonstrated the use of optical communication links for symmetrical and bi-directional high data rate links in combination with low-latency channel coding for very low round trip times comparable to a LEO scenario.

With the use of the Micro Laser Terminal, designed for airborne applications, of ViaLight Communications and the Transportable Optical Ground Station of DLR, the requirements defined by DLR’s Robotics and Mechatronics Center have been verified in an inter-island demonstration campaign on the Canary Islands. This paper gives an overview of the robotic scenario, experiment setup and measurement results for data rate, throughput, bit error rate, packet error rate and round trip times.

I.

SCENARIO DESCRIPTION AND REQUIREMENTS

Robotic operations for applications like exploration of remote planets require powerful communication links in order to send control signals to the robot, but also to receive status information and video data for control purposes. The high data rates enabled by optical technology are especially relevant for the return link, where e.g. Stereo HD video needs to be transmitted. However, also the forward link may benefit from the higher data rates, better power efficiency and lower volume offered by optical links. A number of entities around the world are dealing with the development of optical links in a satellite environment [1, 2], and with the first systems becoming operational [3]. It thus seems to be a logical step to evaluate in a realistic scenario, if the control of robots can be handled with the impairments by optical data links, as e.g. long signal outages due to fading. Therefore, the goal of the HICLASS-ROS project is to demonstrate the applicability of optical data links for robot control in an ISS-to-Earth scenario. In order to simulate the atmospheric conditions between a spacecraft and Earth, a ground-to-ground path between the Canary Islands of Tenerife and La Palma was selected. The turbulence conditions in this atmospheric path can be considered “worst-case” compared to the real LEO-downlink scenario.

Robotic missions can be done using different approaches with respect to autonomy, ranging from fully autonomous systems to pure remote control with direct sensory feedback. Each approach has different requirements with respect to available communication links. A fully autonomous system just requires gross commands of action to complete missions on its own and only reports back the state of the mission. A supervisory control or semi-autonomous system is able to complete disjointed tasks, like grasping known objects. These tasks can be chained to execute a mission. An operator always supervises the mission state and can change the mission plan in any state, as well as update the database of available tasks. In a shared control system, an operator is in the loop of actions, but several functions are automatically taken care of, like finger placement on objects, obstacle avoidance and so forth. In a telepresence system, the operator’s movements are directly reproduced by the remote system, and the sensory feedback is displayed intuitively to the human operator. Shared control systems will be treated as telepresence systems, as these provide more strict requirements. An example of a remote manipulation system consisting of the multimodal human machine interface named HUG and the two armed remote operator named SpaceJustin employing shared control or telepresence approaches is shown in Figure 1.

Figure 1:

Operator using HUG to control SpaceJustin

Furthermore, most complex robotic systems require a variety of exchanged data from the operator to the remote systems with different requirements for each of these data streams. These can be classified by their time relevance ranging from no actual limits (i.e. software updates) to near instant (closed-loop control). The classifications are termed bulk data (high data volume, no time-relevance, highly compressed), telemetry data (low to medium data rates with medium time relevance (seconds), medium compression schemes) and telepresence data (medium data rates with high time relevance and varying compression schemes). Bulk data pools up data which is just classified by its size, e.g. 3D models of the environment, navigation maps, software updates, data loggings and so forth. Telemetry data is a live feed of a decisive state of the system and also incorporates command data. Telepresence data lumps up different modalities (haptic, video and audio) with different requirements. The requirements derived for each modality are chosen to have a minimal impact on the performance of the system while obeying physical realities. Using considerable worse communication links will still result in usable systems, but with considerable impact on overall performance.

The requirements on the communication link can be described using a set of parameters: {minimum packet rate (mpr), data rate, maximal mean round trip time (mmrtt), jitter and packet loss}. Different data types have different requirements for different grades of autonomy. Therefore, for each system and data stream a set of requirements is defined, so-called Quality of Service (QoS) levels. This approach allows for a relaxation of the requirements on the overall communication. Data rate considerations for the presented requirements are based on a humanoid system with two arms and hands, a head as well as a torso and some means of movement and environment perception. For the video transmission multiple high definitions video cameras are assumed. The audio data is based on receiving stereo high definition or communication with an astronaut on site. For telepresence systems communications setups with ideal (<1ms) round trip times are discerned from feasible ones (<700ms). This translates to orbits smaller 150 km or orbits in between 150 km and 100000 km. An overview of possible sets is presented in Table 1.

Table 1:

Quality of Service levels

For the HiCLASS demonstration campaign, the following parameters have been defined as requirements, based on the robotic operation:

II.

MEASUREMENT SETUP

For the evaluation of the feasibility of an optical communication link for robotic operations, an inter-island link between the island of Tenerife and the island of La Palma has been chosen with the expectation of comparable channel conditions to a LEO scenario. The following chapter gives an overview of the measurement setup including the components of the OCB.

A.

Inter-Island Link

The measurement setup has been set up between the island of Tenerife and the island of La Palma in the Canary Islands. Figure 2 shows the link between the islands, indicated by a red line. Due to the height profile of the link, the observed channel characteristics on the 144 km link are comparable to a LEO downlink scenario. Due to the negative elevation of the link and the long distance within the atmosphere, the conditions can even be considered as a worst-case scenario.

Figure 2:

Inter-Island measurement setup with height profile

On Tenerife, the Micro Laser Terminal (MLT, see section B) of ViaLight Communications (VLC) has been installed in the ESA Optical Ground Station (OGS). The MLT is acting as space terminal in the measurement setup. On La Palma, DLR’s Transportable Optical Ground Station (TOGS, see section C) has been operated in front of the Nordic Optical Telescope (NOT; www.not.iac.es). In the measurement setup, TOGS is acting as the optical ground station. Figure 3 shows the setup with a link distance of 144 km between the islands. On both ends of the link, DLR’s Laser Ethernet Transceiver (LET) has beene used for the channel coding. The LET is based on a FPGA which performs a bit-level coding and decoding. The requirements in the QoS with PER and RTT mainly influence the implementation of the channel coding in LET. While a strong error correction is required to achieve low PER, also the delay for coding and decoding is very limited due to the RTT.

Figure 3:

Measurement setup with equipment

B.

Micro Laser Terminal

The Micro Laser Terminal (MLT-20) was developed for aeronautic optical communication scenarios for the transmission of large data volumes between flight platforms and from flight platforms to ground. MLT-20 has a compact size, low weight (5-10 kg depending on the installed features) and typically consumes 80 W. The structure is designed to cope with high vibration and shock levels on flight platforms. It already features a major part of the functionality and geometry required for a future LEO terminal for the final application that has been under investigation in this measurement campaign.

To prepare MLT-20 for the measurement campaign, several modifications on the existing terminal have been made. The data receiver unit has been introduced to enable bidirectional communication. This required a modification of the optical system in order to direct the portion of received light into the data receiver. In standard configuration, the MLT-20 transmits 1W optical power. In order to simulate the conditions in a future LEO to ground link scenario, the transmit power was reduced in the experiment to 100 mW. This lowered the power consumption of the unit by 30 percent. The transmission beam divergence was also significantly reduced according to the link budget representing the LEO to ground scenario.

Figure 4 shows the MLT-20 mounted inside the ESA’s OGS at the Teide Observatory on Tenerife with direction towards La Palma.

Figure 4:

MLT-20 installed in the ESA OGS on Tenerife

C.

Transportable Optical Ground Station

TOGS is used as a ground station within the measurement setup. It features a pneumatically deployable Cassegrain telescope in Ritchey-Chrétien architecture with 60 cm main mirror diameter and 15.8 cm secondary mirror diameter. Both mirrors are manufactured from aluminum for robustness. The TOGS telescope can be folded inside the main compartment and can be ascended to a height of 3 m. A picture of the TOGS in front of the NOT is shown in Figure 5 and outside the transportation vehicle in Figure 6. The station is supported by four manually mounted support legs that provide levelling and compensating for ground roughness. Key specification of the TOGS used in the project is depicted in Table 2.

Figure 5:

TOGS in front of the NOT

Figure 6:

TOGS outside transportation vehicle

Table 2:

Key specification of the TOGS for HiCLASS-ROS project setup

Parameters	Value	Comment
Aperture	60 cm	Good for aperture averaging
Mass	500 kg	Suitable for airborne shipping
Elevation range of telescope	-15°…90°	no blind cone at nadir
Azimuth range of telescope	360°	unlimited travel through slip-rings
Optical Tx-power	2 x 5 W	via Erbium Doped Fiber Amplifier (EDFA)
Tx-wavelength	1560 nm	Tx and Rx signals are separated chromatically
Rx-wavelength	1545 nm
Tx/Rx-data-rate	Up to 1.25 Gbps	Switchable between 100Mbs and 1Gbps
Data link protection	Erasure-FEC by LET-device	FPGA-modem “Laser Ethernet Transceiver” (LET) for error protection against fading-outages, allowing different data rates and protection strength

The TOGS comprises of transmitter and receiver configuration. Knowing the GPS position of the counter terminal i.e. MLT, TOGS is able to points towards the MLT open-loop and transmits a beacon signal which is modulated with the data to be transmitted. The beacon system of the TOGS is made of two separated laser sources to achieve transmitter diversity. Each of them consists of a modulated laser diode, an optical amplifier and a collimator. Once the beacons signal from the TOGS is visible to the MLT, it tracks the TOGS beacon and starts transmitting the signal.

The optical signal from MLT received at the telescope propagates through the optical system which is mounted behind the telescope. The optical system of the TOGS telescope is shown in Figure 7. The signal received at the telescope is directed to two different paths by a beam splitter cube. 10% of the signal is going to the infrared tracking camera for closed-loop tracking of the MLT and remaining part of the signal is focused at the receiver front-end (RFE) which converts the optical signal to an electrical signal. This signal acts as an input signal to the LET for further processing.

Figure 7:

Optical system of the TOGS telescope

To simulate a LEO downlink scenario in this measurement campaign, the collimator divergence of the TOGS has been reduced to the required 100μrad for a LEO constellation. For alignment of the collimators, a truncated retro reflective cube has been used. The cube reflects incoming light from the transmitting collimator mounted close to the telescope back into the telescope, maintaining the direction of light. The reflected light travels through the optical system of the telescope and is focused on the tracking camera. Here it can be observed as a spot, which can be used to align the collimators to the tracking target. The procedure is sketched in Figure 8. Together with a high precision mount for the beacons, the retro-reflector allows for a stable alignment of the beacon system towards the tracking target MLT.

Figure 8:

Alignment of Beacon Laser using a Retro-reflector

III.

MEASUREMENT RESULTS

The objective of the HiCLASS-ROS measurement campaign is to provide reliable communication over an optical link with low latency. In this regard, the media converter LET [4] has been used, developed by DLR. LET is a fully bidirectional system which formats and protects the data in order to overcome the spurious effects of the free-space optical communication (FSO) channel. On the transmitter side, LET encapsulates, protects, and formats Ethernet data received from the user interface and transmits it through a FSO channel. The already converted into electrical signals are processed by the receiver side of LET. The data is corrected whenever it is possible, then the Ethernet frames are extracted and provided to the user interface. LET also ensures that only correct Ethernet frames are forwarded towards the user interface. Figure 9 shows an example of an eye-diagram, measured during an early morning experiment.

Figure 9:

Eye-diagram on TOGS side during early morning measurement

A.

LET internal measurements

The LET version used for this experiment includes a LET frame data encapsulation and a line coding layer through a Reed-Solomon code in a RS(204,188) configuration. This code provides an equivalent gain in power over 3dB [5] and it is used to correct errors caused for soft fades. It also uses an 8B/10B channel coding for ensuring the DC balance of the signal. It provides a user throughput in full compliance with the standard IEEE 802.3 for 100 Mbit/s with a data rate in the line of 137.5 Mbit/s.

Figure 10 shows a 350 seconds sample of a noisy channel. In this measurement, windows with error free communication on user level up to 30 seconds have been achieved. The noise level can be appreciated by the symbol error rate (SER) whereas the packet error rate (PER) indicates that the user data is being properly decoded. An error floor of 10^-12 has been selected to indicate the absence of errors in the given sample. These measurements have a temporal resolution of one second therefore it is not possible to define an exact limit in the SER that will warranty a PER of 10^-12.

Figure 10:

SER and PER results measured by LET during a 350 seconds window

The measurement setup allows measuring the RTT at different positions in the link with the LET itself and additional network performance testers for a user level RTT. LET measures the RTT in each end of the system. It starts with the transmission of a RTT packet which shall be decoded properly at the other end. The time stamp at generation is saved in order to compute the RTT. Once decoded, a response packet is send back to the original LET system that generated the RTT packet. Once this response is decoded, the current time stamp is compared with the time stamp at generation and the final RTT calculated.

Figure 11 shows the behavior of the RTT as well as its average value centered around 1.105 ms. The oscillation in the measurements is caused by the internal structure of the system and the generation of the different packets. This oscillation causes a maximal deviation from the average of 15μs. Additionally, it is important to notice that flying time of the data over the long distance is circa 0.97 ms of the overall RTT.

Figure 11:

Round-Trip Time measurement

B.

Final user results

Despite the relevance of the data acquired by the LET system in order to understand the interaction of the LET system with the channel, the experiment has also been analyzed from a user point of view. It provides common reference frame that can be used to deeper understand possible applications of a FSO communications system such as LET. In this regard, Figure 12 shows that throughputs of 100Mbit/s following the IEEE 802.3 standard can be achieved in this kind of scenarios.

Figure 12:

Percentage of transmitted and received data over 360 seconds

Additionally, Figure 13 presents the statistics of the RTT measured at a user level. The increment of circa 0.5 ms with respect to the RTT measured from LET (compare Figure 11) is caused by the Ethernet interface and storage of Ethernet frames in the communication chain.

Figure 13:

User level RTT

These maximal mean RTT, the jitter and the minimal packet rate will have no impact on the performance on teleoperation systems, besides the one inherent to the signal propagation delay. The achievable data rates are high enough for a multimodal humanoid teleoperation system. The mean packet loss is low enough to not cause any issues. The 1 s windows of the packet loss statistics do not allow for a more detailed analysis of the impact on a human in the loop system (telepresence or shared control), though it has no impact on other teleoperation systems.

IV.

SUMMARY AND OUTLOOK

With the HiCLASS-ROS project, it has been demonstrated that the laser link technology used in this setup is very well suited to be used in future robotic scenarios. With the presented QoS solutions, an optical link can be setup and it has been demonstrated that it can be used for various operational scenarios, from full tele-operated robot control to shared and full autonomy.

The test campaign has proven that the setup is robust and has a margin to provide acceptable communication quality even in arduous channel conditions. However, it turned out during the experiments, that the measurement scenario with the inter-island architecture is very challenging in terms of atmospheric conditions. During bad channel conditions, few requirements were slightly out of the pre-defined range. Nevertheless, the atmospheric conditions can indeed be seen as worst case scenario. In an actual satellite-to-ground link, it can be expected that all defined requirements can be met with suitable margin.

Further tests and scenarios shall include the implementation of the QoS in the communication hardware. Existing hardware has to be adapted to the final link scenario. Adaptation will be preceded by test campaigns involving actual robots and different test environments. Of course, the overall challenging future development is focused on a space experiment with a space terminal aboard a satellite or with the ISS.