1 Introduction

The German Federal Police for Maritime Tasks (Bundespolizei See) is responsible for border control in North and Baltic Sea, surveillance of maritime traffic, and investigation of violations against environmental or fishing regulations [1]. Maritime police operations can be enhanced by remotely piloted aircraft systems (RPAS) operated from ships. Highly automated unmanned systems can for example provide real-time surveillance also in geographically or climatically challenging, or safety-critical situations. The DLR Institutes of Flight Guidance and Flight Systems have been cooperating with the German Federal Police to explore the potential of maritime RPAS operations.

In two consecutive projects named MaRPAS (Maritime Operation of RPAS) requirements and possibilities for the deployment of RPAS in the maritime area are investigated. The common objective is the concept, simulation and execution of precision approaches to a ship deck, even in severe weather. This includes research on legislative requirements, demand analysis of the German Federal Police, and development of new technology towards automated tethered ship deck landings with an RPAS. For the project activities, DLR’s Autonomous Research Testbed for Intelligent Systems (superARTIS) [2] was selected as a testbed.

Two main techniques have been chosen to support ship deck landings: First, a landing system with a newly developed cable winch, and second a precise navigation using global navigation satellite systems (GNSS). The combination of both allows for accurate navigation during missions as well as safe landings on moving landing platforms.

The first MaRPAS project has successfully been completed with a landing demonstration on a real ship deck while the ship was moored in a port. In the ongoing follow-up project MaRPAS 2 the landing system is further refined and adapted to more realistic maritime scenarios, including the landing on a fully moving platform.

1.1 Related work

Ship deck landing of a manned or unmanned rotorcraft is a demanding task especially under severe weather conditions. For manned helicopters, recovery systems such as RAST (Recovery Assist, Secure and Traverse) have been used for many decades [3]. Here, helicopter and ship connect via a cable for tethered landing and finally locking the rotorcraft on the ship deck.

The suitability of a certain aircraft for operation from a dedicated vessel can formally be evaluated by dynamic interface testing or helicopter/ship qualification analysis [4]. Ferrier et al. [5] are also applying these testing methods to unmanned aircraft.

Gautam et. al [6] give a compact overview of general autonomous landing techniques for UAVs (Unmanned Aerial Vehicles). The various techniques are roughly divided into GPS or GNSS-based, vision-based (object detection or pattern recognition), guidance-based (trajectory, proportional or pursuit guidance) and recovery landings (net, airbag, or arrested landing with cable and hook).

Optical ship deck detection is popular for UAVs due to the low weight and cost for optical sensors [7]. Tethered landing systems are usually more complex but offer the additional benefit of stabilisation during take-off and landing as well as on the deck. Successful cable landings for unmanned systems on a (land-based) moving platform have recently been reported by Alarcón et al. in [8].

While GNSS navigation for RPAS is not different than for any other user, some issues arise when considering RPAS operations. First of all, a small size RPAS might need to land in a spot that is smaller than the standard positioning service accuracy of one to three meters. A second problem arises when the landing platform is moving. In this case, the location of the landing site in space must also be updated in real time. When using individual positions from satellite navigation, the position variance will double as both RPAS and landing platform are moving. To perform accurate RPAS operations, the quality of the position used for the RPAS steering needs to be improved. While the first issue can be solved by augmentation systems or carrier phase-based navigation, the use case for the moving landing platform would be better served by a relative positioning system as described in [9]. Further information on navigation concepts for RPAS can be found in [10].

1.2 Organisation of the paper

After this introductory part, the maritime conditions are characterised that define the future field of operation of the RPAS. The next section describes the development of the tethered landing system. Afterwards, the precise navigation algorithm is presented. Finally, the paper reports on the landing demonstration on a real police ship deck. The paper is concluded with an outlook on ongoing work and final remarks.

2 Maritime conditions

Operating an unmanned aircraft under offshore maritime conditions is often more demanding than onshore operations. Before the development of the landing system was started, the conditions that the RPAS would have to face were evaluated. In June 2017, the ship BP21 “Bredstedt” of the German Federal Police was equipped with sensors of a weather station and a four antenna GNSS attitude system to assess the wind situation above the landing deck and to record the ship’s motion and position during a typical mission. The GNSS system recorded data with a frequency of 20 Hz. In total, 7.16 GB of data was recorded and analysed.

The Bredstedt BP21 is a 65.4 m long vessel (type P 60), equipped with a helipad suitable for light helicopters. It has been operated by the German Federal Police mainly for coastal protection operations in the North and Baltic Sea between 1989 and 2018 [11].

In addition to the official mission route, the ship’s captain was asked to drive a pattern containing five legs (see Fig. 1). The ship’s course is marked red, the wind (white) and wavefront (blue) directions during the execution of the pattern are marked with arrows. The wind and wavefront data were provided by the German weather service.

Fig. 1
figure 1

Ship’s course (red) to record wind (white arrows), wave front is plotted as blue arrows

Full size image

Each leg of the pattern can be distinguished by the angle between the ship’s course and the wind direction as follows:

  • Leg 1: headwind

  • Leg 2: left 90° crosswind

  • Leg 3: downwind

  • Leg 4: right 90° crosswind

  • Leg 5: left 30° crosswind.

The determination of different legs allowed consideration of different wind scenarios on the landing deck and ship motions. Leg 5 represents the desired scenario for RPAS recovery. The ship’s course of 30° relative to the wind should reduce the air wake turbulences over the landing deck while creating an almost frontal inflow for the RPAS. This leg is defined as the ship’s standard procedure for take-off and landing of RPAS and will be further analysed in the remaining section.

The weather station consists of an ultra-sound sensor array to measure the wind-vector in three dimensions and a temperature sensor, which was used to correct the ultra-sound data. The recorded wind vector in the horizontal plane during the pattern is displayed in Fig. 2. The blue graph shows the measured values while the red graph displays the average of a moving 100 s wide window. Maximum averaged wind speeds were measured at over 15 m/s. The German Federal Police wishes to use RPAS support up to wind speeds of 5 Bft (< 11.3 m/s). In experimental mode, the superARTIS can currently be operated safely at wind speeds up to 3 Bft (< 5.7 m/s). Therefore, the experimental demonstrations have to be limited to conditions with only moderate wind. In future developments, drones with higher wind capability will be used. Thus, the system will have to be adapted to higher wind speeds.

Fig. 2
figure 2

Recorded wind data in the horizontal plane

Full size image

Based on the position data, recorded by the GNSS system, the velocity and acceleration of the ship could be calculated, yielding an estimate of required reaction time frames of the unmanned rotorcraft. During the relevant recovery leg 5 the ship’s velocity was between 5.7 and 6.6 m/s (see Fig. 3).

Fig. 3
figure 3

Recorded velocity and course of the ship

Full size image

The capability of the GNSS receiver to record attitude data allowed the analysis of the ship’s roll, pitch and yaw angles and rates. The roll and pitch angles and according angular velocities are displayed in Figs. 4 and 5. The ship is equipped with a subsequently installed active stabilizer. Thus, relatively low roll angles of up to 2.6° and pitch angles of up to 2.3°, which are uncritical for a safe landing of the superARTIS, were measured in leg 5.

Fig. 4
figure 4

The ship’s roll motion

Full size image
Fig. 5
figure 5

The ship’s pitch motion

Full size image

3 Tethered landing system

There are three main technical challenges of a shipboard landing. First, for touch-down the RPAS has to be aligned with the ship deck during descent. Depending on the weather condition, sea condition, and the ship’s speed and course with respect to the direction of wind, sea current, and wavefronts the landing deck may perform significant heave, roll, and pitch motions [12]. These motions are critical for shipboard landings as they influence the landing shock and rotor clearance of the RPAS at touchdown. Thus, these motions must be compensated by the RPAS.

Second, strong wind and wind fluctuations such as gusts and air wakes induced by the ship superstructure interact with the RPAS’s aerodynamics decreasing the RPAS’s ability to align properly with the ship deck.

Third, currently available RPAS are significantly lighter than manned aircraft resulting in lower stiction on the deck. Thus, RPAS are more susceptible to slide or tip over due to the wind forces or ship deck motions. That means after successful touch down the RPAS must be secured immediately. As currently applied procedures prohibit human access to the vehicle before engine shut-down, the RPAS must be secured by an independent technical system.

Within the MaRPAS project a tethered landing system, which is able to cover all three introduced challenges, was developed and eventually demonstrated. The landing system works similar to the Recovery Assist, Secure and Traverse (RAST) system, also known as “Beartrap”, which is successfully used in manned aviation for many decades [3]. Both systems have in common that the approaching aircraft connects itself with a cable to the ship deck. The cable provides a stabilizing moment on the aircraft as an aircraft-specific tension is applied [4]. The principle of using a cable is very robust and does not require complex sensor and software solutions. After touch-down, the cable is used to secure the aircraft.

The MaRPAS landing system consists of two devices: (1) a portable winch that can be lowered from the RPAS to the landing deck where it connects to the ship and (2) a connection unit mounted under the RPAS between the landing gear. The portable winch is applied for patent [13]. Figure 6 displays the winch while being lowered from the RPAS to the landing deck.

Fig. 6
figure 6

Portable winch device being lowered

Full size image

Figure 7 gives an overview of the connection unit and the winch’s design. The connection unit aboard the RPAS consists of a 3-axis force sensor (1). The sensor is used to determine the cable force and direction, which may be used in the future as an additional navigation source, as shown in [8]. An electromagnet (2) is mounted on the force sensor and is used for emergency decoupling from the cable (4). The cable is connected to a magnetisable counterpart (3) for the electromagnet on one side and on the other side connected to a spool (7) inside the winch. The spool is driven by a DC motor. The DC motor is controlled by a microcontroller (8) and powered by two accumulators (9) and (10). A double-helix screw (6) helps the cable to properly line up on the spool. A locking mechanism (5) connects the winch to the helicopter and stows the winch between take-off and landing.

Fig. 7
figure 7

Schematic design of the portable winch

Full size image

The winch uses an electromagnet (11) to connect with the surface of the landing deck. However, as most ships have landing decks made from aluminium the magnet may be replaced by e.g. a form-fitting connector. The current operation mode of the winch is indicated by circumferentially installed multicolour LED lights.

A detoriated navigation solution or strongly fluctuating winds may cause the winch to not properly centre on the landing deck after it was lowered from the RPAS. Thus, the winch can be re-positioned by a crew member on the deck. The crew member re-positions the winch by grabbing the winch on its handle and, by pushing the integrated button (13), deactivating the electromagnet (11). The electromagnet (11) is reactivated at the new position when the button is released.

The use of a portable winch means that the winch has to be carried as a dead weight during missions. The prototypical winch system has currently a weight of 3.5 kg but can be optimized to a lower weight. The tethered landing system requires that the RPAS is precisely guided to a point above the landing deck e.g. by a GNSS based navigation system as introduced in the following section. The precise navigation is crucial for correct positioning of the RPAS during the winch deployment so that the winch is placed in the very center of the landing deck.

The main advantage of the portable winch is that it does not require specific changes to the landing deck’s infrastructure. Thus, the system can be used on various ship types including ships without any infrastructure. The only requirement is that the ship provides a corresponding part to the winch’s connector mechanism.

4 Navigation

A standard positioning service used in UAV control is differential GPS, with the master station usually located at the site of the RPAS control station. In differential GPS, the master station uses its location to compute differential pseudo range corrections, which are then transmitted to the vehicle (called “rover” in GPS terminology), applied there and used to compute a “corrected” position [14]. In case the location of the master’s reference antenna is not precisely known, this error is propagated to the rover and added to the positioning error of the rover. As long as one is not interested in the precise absolute position of the rover vehicle system, no harm is induced using this technique. However, if the master is moving as well, a new reference position must be calculated at every epoch and by the laws of error propagation the rover’s position measurement standard deviation doubles [15].

Another possibility to obtain a similar accuracy and integrity without the need for a costly and lengthy installation would be to use a GNSS receiver as a "beacon" and compute a relative 3D position between this beacon and an airborne receiver. Using a relative position vector, the need for precisely measured reference antenna locations is eliminated and, when using a well-known technique called double differencing, any correlated errors are removed. Normally, double differencing is used when resolving the GPS signals carrier phase ambiguity during post-processing of data or for real-time kinematics applications [16]. We form the double differences based on code measurements. (The description of the following navigation algorithm has previously been published in [9] and [17]. Further details on the method can be found there.) We assume that pseudorange between receiver \(k\) and satellite \(p\) can be modelled as

$$\rho_{k}^{p} (t) = r_{k}^{p} + c(\delta^{p} (t) - \delta_{k} (t)) + Q_{k} + \gamma_{{{\text{iono}}}} (t) + \gamma_{{{\text{tropo}}}} (t)$$
(1)

with \({r}_{k}^{p}\) the geometric range, \({\delta }^{p}\) and \({\delta }_{k}\) the satellite and receiver clock biases, \({Q}_{k}\) the receiver noise, \({\gamma }_{\mathrm{iono}}\) the error induced by the ionosphere and \({\gamma }_{\mathrm{tropo}}\) the error induced by propagation through the troposphere. To suppress errors correlated with one particular satellite such as the clock bias \({\delta }^{p}\), we form the single difference \((SD)\) pseudorange, between the measurements of two receivers \(k\) and \(m\). Because of the proximity of our two receivers, we assume for the remainder of this section that the ionospheric and tropospheric delays between receiver \(k\) and \(m\) are the same and can also be removed.

$${\text{SD}}_{km}^{p} = \rho_{m}^{p} - \rho_{k}^{p} = r_{km}^{p} + Q_{km} + c(\delta_{k} - \delta_{m} )$$
(2)

is the difference between the raw pseudoranges of receivers \(k\) and \(m\), for satellite \(p\). It corresponds to the difference of geometric ranges, plus a term \({Q}_{km}\) of noise and multipath, and the remaining receiver clock biases. The satellite bias \({\delta }^{p}\) is common to the two pseudoranges and was thus canceled by the difference. We can also express the \(SD\) as a function of the baseline between the two receivers by linking the baseline with the differential geometric range \({r}_{km}^{p}\). This is analogue to the principles of interferometry.

Let \(k\) and \(m\) be the phase center of the antennas, and \(\vec{b}\) the unknown baseline vector between them (see Fig. 8). Knowing that the satellite \(p\) is at a distance of about 20,000 km, we can assume that the paths of propagation between the satellite and the two antennas are quasi parallel. We also know the line of sight vector \({\vec{e}}^{\vec{p}}\) to the satellite \(p\). The Single Difference can easily be expressed as the projection of the relative position vector onto the line of sight vector to the satellite \(p\). The differential geometric range \({r}_{km}^{p}\) can thus be expressed as the scalar product between the unit vector \({e}^{p}\) and the baseline \(\vec{b}\):

$$r_{km}^{p} = \mathop {\vec{e}}\nolimits^{{\vec{p}}} \cdot \vec{b}$$
(3)
Fig. 8
figure 8

Simplified geometry of the double differencing process. The three-dimensional baseline b is determined through measurements taken at two GNSS receivers k and m

Full size image

This means for the single difference equation

$$SD_{km}^{p} = \mathop {\vec{e}}\nolimits^{{\vec{p}}} \cdot \vec{b} + Q_{km} + c(\delta_{k} - \delta_{m} )$$
(4)

We still have the error due to the receiver’s clock bias in this equation. To remove this term, we form the difference between the \(\mathrm{SD}\) of the same two receivers but with another satellite \(q\)

$${\text{SD}}_{km}^{q} = \mathop {\vec{e}}\nolimits^{{\vec{q}}} \cdot \vec{b} + Q_{km} + c(\delta_{k} - \delta_{m} )$$
(5)

then differentiate the two \(SD\) equations yielding a double difference \(DD\):

$$\begin{aligned} DD_{km}^{pq} & = SD_{km}^{p} - SD_{km}^{q} = (\rho_{m}^{p} - \rho_{k}^{p} ) - (\rho_{m}^{q} - \rho_{k}^{q} ) & \\ = (\mathop {\vec{e}}\nolimits^{{\vec{p}}} - \mathop {\vec{e}}\nolimits^{{\vec{q}}} ) \cdot \vec{b} + Q_{km}^{pq} \\ \end{aligned}$$
(6a)

with

$$Q_{km}^{pq} = (Q_{k}^{p} - Q_{m}^{p} ) - (Q_{k}^{q} - Q_{m}^{q} )$$
(6b)

corresponding to the noise and the multipath of all the receivers. Dropping the vectorial notations and ignoring the noise term, the double-difference becomes:

$$DD_{km}^{pq} = (\mathop {\vec{e}}\nolimits^{p} - \mathop {\vec{e}}\nolimits^{q} ) \cdot \vec{b}$$
(7)

which can be solved using standard least-squares methods. Using matrix notation yields the following equation:

$$DD_{pr} = H \cdot \vec{b}$$
(8)

Note that the geometry matrix \(H\) contains the difference between unit vectors to different satellites for all possible satellite combinations. Therefore, this method does not have the inherent shortcomings of the GNSS position solution. In the GNSS position solution, due to the unavailability of measurements from below the user, the vertical precision of the solution is less than the horizontal. Here, due to the differencing, this vertical dilution of precision is mitigated. The baseline \(b\) can then be obtained using \(S\), the pseudo-inverse of the Geometry Matrix \(H\)

$$b = S \cdot DD_{pr}$$
(9)
$$S = (H^{T} H)^{ - 1} H^{T}$$
(10)

Beyond a certain baseline, the assumption that the paths of propagation between the satellite and the two antennas are parallel is no longer valid. We analysed the impact of this hypothesis, by taking into account the angle \(\beta\) between the two paths of propagation to compute the remaining error brought by this hypothesis, and thus correct our estimated baseline. We calculate again the baseline using the double-difference method, but by taking into account the angle \(\beta\) between the two paths of propagation. The baseline \(\vec{b}\) can be expressed as

$$\vec{b} = r_{1} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} - r_{2} \cdot \mathop {\vec{e}}\nolimits^{{\vec{2}}}$$
(11)

The scalar product between the baseline \(\vec{b}\) and the unit vector \({\vec{e}}^{\vec{1}}\) becomes

$$\begin{aligned} \vec{b} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} & = (r_{1} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} - r_{2} \cdot \mathop {\vec{e}}\nolimits^{{\vec{2}}} ) \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} \\ & = r_{1} - r_{2} \cdot \mathop {\vec{e}}\nolimits^{{\vec{2}}} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} \\ \end{aligned}$$
(12)

knowing that \({\vec{e}}^{\vec{1}}\) and \({\vec{e}}^{\vec{2}}\) are unit vectors:

$$\begin{aligned} \mathop {\vec{e}}\nolimits^{{\vec{2}}} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} & = cos(\beta^{p} ); \\ \vec{b} \cdot \mathop {\vec{e}}\nolimits^{{\vec{1}}} & = r_{1} - r_{2} + \underbrace {{r_{2} (1 - cos\beta^{p} )}}_{additional - term} \\ \end{aligned}$$
(13)

Thus, we have to add a remedial term to the former single difference \({SD}_{km}^{p}\), which becomes

$$SD_{km}^{p} + r_{m}^{p} (1 - cos(\beta^{p} )) = \vec{b} \cdot \mathop {\vec{e}}\nolimits^{{\vec{p}}}$$
(14)

The double difference then becomes:

$$DD_{km}^{pq} + r_{m}^{p} (1 - cos\beta^{p} ) - r_{m}^{q} (1 - cos\beta^{q} ) = (e^{p} - e^{q} ) \cdot \vec{b}$$
(15)

5 Navigation trials

To assess the performance of the code based double-difference relative position, we placed two antennas on the roof of the DLR Institute of Flight Guidance in Braunschweig, Germany, separated by a distance of (8.6016, − 1.1054, 0) meters in East, North and Up direction, respectively. The antennas were a Novatel Pinnwheel and a Leica AR20 GNSS reference antenna. They were connected to Topcon NetG3 and Javad Quattro receivers, respectively.

Using our own real-time processing code, we collected baseline data for about six days to compare with the real relative position. Moreover, we recorded for each epoch the relative position variance–covariance matrix.

In a north-east-up coordinate system, the standard deviations are 0.2155 m, 0.2729 m and 0.4692 m, respectively. The off-diagonal covariances were one order of magnitude smaller (see Fig. 9). These results show the improved accuracy of the double-difference algorithm compared to the standard positioning service accuracy of one to three meters.

Fig. 9
figure 9

Histogram of the data collected during 6 days. The standard deviations are 0.2155 m, 0.2729 m and 0.4692 m in East, North and Up direction, respectively

Full size image

6 Landing demonstration

The first MaRPAS project was concluded with a final demonstration of the feasibility of the landing system. The demonstration was conducted in October 2018 in the port of Hohe Düne in Rostock-Warnemünde, Germany. The helipad of the “Bredstedt” BP21 was used as a landing platform while the vessel was moored in the port.

The superARTIS testbed used for the demonstration is a swissDrones Dragon 50 helicopter with two intermeshing rotors. Table 1 displays a short selection of superARTIS’ aircraft specifications.

Table 1 SuperARTIS aircraft specifications
Full size table

The superARTIS was equipped with the landing system, while the antenna system required for precise navigation was installed on the ship (see Fig. 10). The four antennas of the ship-based GNSS attitude system were distributed in a tetraheadron configuration around the ship; one at the bow, one above the bridge and two on the edge of the helicopter landing platform facing the bow. The rover was equipped with a Novatel OEM617D GNSS heading receiver. The superARTIS operator platform was located next to the crane used for lowering the dinghy.

Fig. 10
figure 10

Final demonstration setup

Full size image

The demonstration of the tethered landing system focused on proving the general feasibility of a tethered landing for RPAS. Thus, superARTIS and the portable winch were controlled manually. The winch operator controlled all winch functions via an RC controller. The superARTIS was manually controlled from a ground control station aboard the ship (see Fig. 11) and the superARTIS base controller supported the pilot’s control commands.

Fig. 11
figure 11

Tethered landing with manually controlled superARTIS

Full size image

Two successful tethered landings were conducted during the demonstration. The recorded flight trajectories are displayed in Figs. 12 and 13. At both landings, the winch was lowered from a height of 15 m to the deck where its magnets connected to a steel plate. The winch was able to maintain tension on the cable during the whole landing process, and the superARTIS eventually touched down almost centrically to the winch.

Fig. 12
figure 12

Side-view on recorded superARTIS flight trajectory

Full size image
Fig. 13
figure 13

Top-view on recorded superARTIS flight trajectory

Full size image

Besides the landings, two take-offs from the landing deck where also performed. One take-off was conducted using the winch as arresting device, demonstrating the system’s ability to hold the superARTIS in position from engine start-up until take-off from the ship deck.

7 Continuing work

Due to a software failure, no double difference relative positions were recorded during the ship deck demonstration. Nevertheless, the results from Braunschweig show its general feasibility. Real-world application scenarios including off-shore operations in severe weather require a precise starting position before utilising the winch. Therefore, in the follow-up project it is planned to further harmonize GNSS navigation and automatic tethered landing.

The next task after a successful demonstration of the tethered landing system is to increase the system’s level of autonomy. This involves the automatization of the portable winch and the development of an automatic approach and winch deployment manoeuvre with according algorithms for the RPAS.

8 Conclusion

This paper has presented a landing system for an unmanned rotorcraft (RPAS) being operated from a ship deck. For take-off and landing, a winch was developed that is carried on-board the RPAS. The winch is connected to the surface of the ship deck via an electromagnet. The winch cable was successfully used for aligning the RPAS over the ship deck during take-off and landing and to secure the rotorcraft after landing. For precise navigation of the RPAS in the vicinity of the ship, double-difference algorithms were used on code measurements.