Control System Architecture for Automatic Recovery of Fixed-Wing Unmanned Aerial Vehicles in a Moving Arrest System

Automatic recovery is an important step in enabling fully autonomous missions using fixed-wing unmanned aerial vehicles (UAVs) operating from ships or other moving platforms. However, automatic recovery in moving arrest systems is only briefly studied in the research literature, and is not yet an option when using low-cost, commercial off-the-shelf (COTS) autopilots. Acknowledging the reliability and low cost of COTS avionics, this paper adds recovery functionality as a modular extension based on non-intrusive additions to an autopilot with very general assumptions on its interface. This is achieved by line-of-sight guidance, which sends an augmented desired position to the autopilot, to ensure line-following along a virtual runway that guides the UAV into the arrest system. The translation and rotation of this line is determined by the pose of the arrest system, determined using two Global Navigation Satellite System (GNSS) receivers, where one is configured as a Real-Time Kinematic (RTK) base station. The relative position of the UAV and arrest system is also precisely estimated using RTK GNSS. Through extensive field testing, on two different fixed-wing UAVs, the system has shown its performance and reliability; 43 recovery attempts in a stationary net hit 0.01 ± 0.25m to the right and 0.07 ± 0.20m below the target in calm conditions. Further, 15 recoveries in a barge-mounted, ship-towed net hit 0.06 ± 0.53m to the right and 0.98 ± 0.27m below the target in winds up to 4 m/s. The remaining error is largely systematic, caused by communication delays, and could be reduced with more integral effect or through direct compensation.


Introduction
Fixed-wing unmanned aerial vehicles (UAVs) are typically superior to similar-sized rotary-wing UAVs using the same energy source when it comes to range, endurance and speed, and is thus the preferred option for many scenarios. While many missions can be flown automatically, possibly interacting with an operator at a ground control station, recovery of fixed-wing UAVs is often a manual task performed by a highly skilled pilot. In addition to the economic benefits of removing the human pilot from the control loop, this also enables operations with a smaller margin of error, as the sensing and control loops of a the possibility to construct a self-contained system that does not rely on external communication or measurements, that delivers relative pose measurements at a high rate, with high precision when close to the arrest system, like e.g [6,11,19,20]. Drawbacks include high processing requirements, risk of false detection, and sensitivity to visual conditions, such as light/weather conditions and distinctiveness of the arrest system relative to its background. The latter can to some extent be mitigated by using infrared (IR) cameras, either using natural landmarks [21,22] or IR lamps in known locations [23].
The arrest system may also be equipped with position sensors such as GNSS receivers [8] or radio beacons, exemplified by ultra-wideband (UWB) [24][25][26], where the main advantage is low cost to the user, small footprint, all-weather availability and ease of use. This is especially true for GNSS, which is already part of most autopilot sensor suites. While the positioning accuracy of a single receiver without augmentation is in the order of meters, depending on whether one or more constellations and a single or dual frequency receiver is used [27], two independent receivers operating within a short distance will have atmospheric errors which are mostly common. This means that relative positioning accuracy between two receivers will generally be better than the absolute accuracy if both receivers track the same satellites and apply the same atmospheric corrections, although this also depends on the multipath situation for each receiver. Space-based augmentation systems (SBAS) can improve the positioning accuracy by transmitting corrections for satellite position errors, clock errors and atmospheric effects to the user from geostationary satellites [27]. Centimeter-level precision, between the UAV and a base station, can be achieved with real-time kinematic (RTK) GNSS [27], a technology that over the last decade has become available to the civilian market at a low cost. GNSS measurements are inherently absolute, so if the arrest system is moving, it must be fitted with a second receiver to obtain the relative position. This also calls for radio communication between the UAV and arrest system. Advantages with UWB, compared to GNSS, include robustness to interference, resistance to multipath [28], as well as high temporal resolution allowing for centimeter level precision of range measurements [29], but the ranges are typically only in the hundreds of meters. By positioning the UWB beacons to move with the arrest system, they can provide a relative navigation solution, possibly at the cost of weaker measurement geometry due to the limited size of the arrest system, leading to lower precision [24]. Drawbacks associated with GNSS include susceptibility to radio frequency interference (RFI), both natural RFI, such as ionospheric scintillations [30] and multipath, and intentional RFI, such as jamming [31] and spoofing [32].
Other relative navigation off-the-shelf options include the laser-based Object Position and Tracking System (OPATS) [33], GPS-and radar-based Dual-Thread Automatic Takeoff and Landing System (DT-ATLS) [34,35], as well as the integrated navigation and control solution UAV Common Automatic Recovery System (UCARS) [36] for ship landing. Although these systems are well proven, they are also proprietary commercial systems with unknown algorithms and with little flexibility to make customizations.
To approach the arrest system from the correct direction, its (relative) heading must be found, from one of the seven ways to estimate heading [37]. The simplest is through a magnetometer/compass, which unfortunately is highly susceptible to magnetic anomalies and electromagnetic interference (EMI) [37]. With a camera, the relative heading angle can be found [6]. Another solution is to equip the arrest system with multiple position sensors to find the orientation of the baseline between them, see e.g. [38] or [39] that reports 0.27 • precision for a baseline of about 0.5,m using GNSS. Depending on the dynamics of the arrest system and the precision requirements, a combination with inertial sensors may be required to provide smoother estimates at a higher rate.
Another important part of the recovery system is guidance and control. For an overview of different control algorithms for fixed-wing UAVs, see [40], and [41] for path following guidance algorithms. The navigation setup tends to dictate requirements for the guidance and control system, where visual servoing methods favor pure-pursuit guidance [6,11], while with the relative navigation between the UAV and arrest system in an absolute frame, the guidance law can be chosen arbitrarily.
This paper seeks to investigate how precisely, accurately and reliably a fixed-wing UAV can land in a moving arrest system, using a control system architecture building modularly and non-intrusively on low-cost commercial offthe-shelf (COTS) hardware (HW) and software (SW). The main contribution is the design and implementation of the landing system SW and HW, in addition to extensive experimental testing. To our knowledge, there are no openly available publications that give a complete description of such a system, so we believe that the description and systematic evaluation herein is a solid foundation for an industrial implementation and future academic research. To be of any operational value, the system must be accurate and reliable enough that the operators have confidence in it, which boils down to repeatability and operability across a wide range of environmental conditions. It should also be precise enough to allow recovery in arrest systems that are of a manageable size. The presented system is based on COTS autopilot HW and SW as they are generally well tested, thus reliable, providing airworthiness and reducing the needs for implementation, possibly at the cost of performance, flexibility and licensing issues. However, they might not provide all the necessary features. Even though some commercially available autopilots are capable of automatic landing in fixed locations, such as [42], this does not suffice for a moving arrest system. Instead of adding the arrest system recovery functionality in a specific autopilot SW, by making possibly error-inducing changes to a working system, this work seeks to build on the existing interfaces of common autopilots by basing the extension on the very general assumption that all autopilots provide an estimate of its position, velocity and attitude, based on internal sensors and an external position measurement, while also providing a means to command the UAV to fly to a specific location. In this work the autopilot is provided with position measurements from RTK-GNSS, due to its simplicity and high precision, but it could in principle come from any position sensor with sufficient accuracy. In addition to non-intrusiveness, these assumptions also make the system modular so that it can be adapted to a wide range of autopilots and fixed-wing UAV configuration, through only a few tuning variables, although this work focus on the open source ArduPlane autopilot software, and is motivated by its current limitations. This is achieved by a line-of-sight (LOS) guidance controller, that ensures line-following of a virtual runway into the moving arrest system, by sending position commands to the autopilot.
The paper is split into two main parts. First, Section 2 describes the recovery system architecture for a general, idealized scenario. This includes the plan generation (Section 2.1), navigation (Section 2.2), motion prediction (Section 2.3), guidance and control (Section 2.4) and operator interface (Section 2.5) subcomponents. The second major part is Section 3, where the general architecture is adapted to a specific arrest system and a specific autopilot, where the implementation in a real-time system is discussed. The implemented system is experimentally validated in two experiments in Sections 4.1 and 4.2, first for a stationary arrest system and then for a moving arrest system mounted on a floating barge towed by a ship. Lastly, in Section 5.1 we discuss the results and mention possible improvements before drawing the conclusion in Section 5.2.

Recovery System Architecture
The control system architecture is presented in this section, by considering each of the functional components that are needed to recover a fixed-wing UAV in a moving arrest system. The system creates the plan, seen in Fig. 1, from parameters set by the operator. As the arrest system is moving, so is the latter part of the plan, which is translated and rotated such that it lines up with the predicted pose of the arrest system at the time of impact. Fig. 1 The geometry of the arrest system recovery plan, illustrated with a net This pose is predicted from precision navigation, that includes compensation for predicted arrest system motion to maximize the chances of impacting near its center. To allow straight-line path-following, while being limited to only sending a position reference to the autopilot, the system is augmented with a line-of-sight guidance that finds an appropriate carrot-point reference that will give the desired behavior. Before impact with the arrest system, the motor is turned off, to avoid damage and severe entanglement.

Plan Generation
A plan can be generated with different objectives in mind. The different objectives are usually a combination of minimizing risk and reducing the effect the recovery has on the rest of the mission, being the primary objective. The presented solution seeks to minimize risk, primarily in three ways. First by maximizing the predictability of the UAV motion, by having the final stages be straight line segments. Secondly, the risk is minimized by delaying the reduction in height as much as possible, to increase the probability of succesful abort in case of an emergency. Lastly, the risk is minimized by reducing the relative speed between the UAV and the arrest system before impact, to not jeopardize the structural integrity of the UAV. However, this speed reduction must not come at the cost of a too low airspeed, to avoid stall, and to maintain enough speed to penetrate wind gusts and shear, as well as overcoming any forces needed to be captured by the arrest system. Based on these strategical decisions, the recovery is divided into the following phases, illustrated in Fig. 1.
Pre-recovery This is when the UAV has finished its mission, and is initiating recovery by flying to the start of the transit phase along an arbitrary path.

Transit
The path toward alignment with the arrest system ends in a 2D Dubins path [43], to bring the UAV to the start of the descent with a correct course angle and altitude. This is an interconnection of circular arcs and straight lines, which, under the assumption of a maximum curvature, is shown to be the shortest path between two poses in 2D, thus minimizing the effect the recovery has on the rest of the mission. The altitude is simply a linear descent at a prescribed angle, γ p,transit , again delaying the descent as long as possible. If the desired altitude at the end of the transit phase is unreachable at this descent rate, the final circular arc of the Dubins path is extended into a spiral to shed the excess altitude.
Alignment When exiting the Dubins path (transit phase), the course should be aligned with the arrest system, but to be sure this course is held for a distance d align , to ensure that the UAV has a stable course.
Approach While maintaining alignment, the UAV descends with a flight path angle γ approach , for a distance d approach .
Final alignment The UAV is now on a virtual runway, starting a distance d final before the arrest system. This runway is guiding the UAV into the arrest system center by continuously aligning itself with the orientation and position of the moving arrest system and the desired landing flight path angle γ final . Speed is reduced to lower the impact, and the engine is turned off to avoid damage to the propeller or arrest system.
Catch After a successful recovery, with stopped/disarmed motors.

Navigation
The success of the recovery hinges on knowledge of where the UAV is, relative to the arrest system. For the presented approach, the self-navigation is assumed to be handled by the COTS autopilot, typically through a Kalman filter based on inertial navigation, aided by a GNSS receiver for position measurements, a compass/magnetometer for heading measurements, a barometer/altimeter for altitude measurements, and a pitot tube for airspeed measurements. These are considered as standard components, since they are part of most autopilot sensor suites.
Instead of only using a standalone GNSS receiver, this work uses Real-Time Kinematic (RTK) GNSS, which has been successfully utilized for similar applications [5,10]. RTK GNSS works by continously sending all raw measurements including carrier phase measurements from a reference receiver, in addition to the reference receiver's own position estimate (as this may be changing over time), to the UAV. The UAV receiver then uses the measurements from both receivers, using a technique based on carrier phase interferometry, to estimate the baseline between them with high accuracy and precision. This works well as long as they are closer than about 20 km apart [44], as the atmospheric signal disturbances have a high degree of spatial correlation such that they are approximately equal for both receivers. It is important to note that the output format of the receiver is the same both when RTK is used and when it is used as a standalone receiver, and where there is a degradation of the RTK capability, e.g. GNSS signal strength drops so carrier phase measurements become unusable, this means that the precision and accuracy of the relative positioning is reduced. RTK GNSS was chosen based on the simplicity of its usage, availability and high precision. Whether the high precision of RTK GNSS is necessary, depends on the size of the UAV relative to the arrest system, but given the availability of low-cost RTK GNSS solutions, it seems tractable. These receivers output position and velocity estimates with high precision and accuracy directly into the autopilot, without the need for any additional computation. If using a widely supported output-data format, such as the NMEA standard, the receiver can easily be replaced, becoming a transparent source of high-precision and high-accuracy estimates to the autopilot.

Relative Navigation Setup
To reap the full potential of GNSS in terms of precision, it is important to make use of RTK processing, providing a precise relative position of the UAV and base. Therefore, the arrest system is equipped with one GNSS receiver acting as an RTK base station. For ship-based recovery in open waters, the only option is a moving-base configuration, where only the precision of the relative position is guaranteed. However, for recovery in stationary arrest systems, the base antenna position can be surveyed, allowing for both accurate and precise, global position measurements. Further, the arrest system is equipped with an additional RTK GNSS receiver, which is used to measure the orientation of the arrest system. During recovery, it is important that the position of the UAV and arrest system are reported in the same frame of reference, with the same origin. This also implies that a barometric pressure sensor onboard the UAV cannot be used as the only source of altitude measurements during the final stages of recovery, unless the arrest system is equipped with barometric pressure sensor that is calibrated to the same level as the onboard pressure sensor, pre-flight, as changes in ground level pressure would lead to drift in the altitude estimate during a flight, which ultimately would cause the UAV to aim above or below the physical arrest system target. Another option is to use a source of altitude measurements without long-term drift, such as RTK GNSS, either as a primary altitude sensor or to correct barometer drift over time.
The arrest system is instrumented with two GNSS antennas, with one antenna positioned in p n left on the left side as seen from the front, acting as the RTK base for the UAV and the second net antenna, which is placed in position p n right on the right side of the arrest system, as illustrated for a recovery net in Fig. 2. The position of the arrest system center in the NED frame {n} with its origin at the position of the left antenna, p n arrest , roll angle φ arrest and heading angle ψ arrest are calculated as  i.e. they can be positioned higher than the center or with different distance to the center on each side. With this antenna configuration, the pitch angle can not be calculated, forcing the approximation R n b ≈ R n b (φ arrest , θ nom , ψ arrest ), where the pitch angle θ nom is a constant nominal value. This encourages a small offset p b offset to minimize position errors. For excessive pitch motion, or large offsets in the xz-plane, an alternative would be to also estimate the pitch angle, using an IMU or a third antenna.

Motion Prediction
In principle, for a successful recovery the UAV only needs to know the relative pose of the arrest system at the time of recovery. However, this can be difficult to predict for moving arrest systems, as the recovery location might not be determined uniquely and with certainty at the start of the recovery plan. Not only is this a chicken-and-egg problem, where the relative position of the arrest system, at the time of recovery, is needed to calculate the time it takes to fly to it (which again is needed to predict the relative position of the arrest system at the time of recovery), but it is also highly dependent on the dynamics of the arrest system. The arrest system can either have accurate, actively controlled motion, such as [8][9][10], which calls for synchronization between the UAV and arrest system, or be passively attached to a moving platform without accurate control, such as a moving ship [4]. Particularly for recovery in smaller arrest systems in space-restricted environments, using less agile UAVs with smaller error margins, good predictions of the arrest system motion will be more important, but the prediction quality naturally depends on how well the arrest system dynamics can be modeled. Given good predictions, the recovery controllers may be less reactive to rapid arrest system motion, thus allowing less agile UAV dynamics.
The proposed system only makes a rough prediction of the position of the arrest system at the time of impact, given its current velocity. The relative position of the UAV and arrest system is calculated as where p n arrest and p n UAV are current position estimates for the arrest system and UAV, respectively, and Δp n arrest is the predicted arrest system movement during the time t impact remaining until impact, using an initial guess. Given this relative position, an estimate of the time until impact is found using the current UAV velocity and a simplifying assumption of straight line flight to the arrest system, which is then used to improve the prediction of arrest system movement, Then, Eq. 4 is used to compute a new prediction of the relative position at the time of impact, and the process is iterated until sufficiently converged. Δp n arrest is initialized as 0, which corresponds to a stationary arrest system, but using the final result from the previous time step at the next time step can reduce the number of iterations needed for convergence.
In the above, no prediction or filtering of the attitude and heave motion of the arrest system is performed, as the time horizon for reliable wave-induced motion prediction for ships may be in the order of a few seconds, due to the stochastic nature of waves [16]. Furthermore, the motions of the arrest system are assumed small compared to the agility of the fixed-wing UAV.

Guidance and Control
To ensure that the UAV follows the final alignment stage of the recovery plan in a manner that is easy to predict by the operator, line-following guidance [41], such as line-of-sight (LOS), is applied in the approach and final alignment stages. LOS guidance [45] mimics an experienced navigator, by aiming to intercept the desired path a time-varying lookahead distance Δ ahead of the current position, see where Δ is the lateral lookahead distance, where y e = − sin(χ p )(x−x k )+cos(χ p )(y−y k ) is the lateral cross-track error, and where χ p = tan y k+1 −y k x k+1 −x k is the course angle of the line segment [45]. This guidance law is extended from [46,47] to also include integral effect. Although the guidance law is formulated using the course angle, which inherently accounts for wind effects, integral effect is still needed to overcome stationary cross-track errors as a result of e.g. uncompensated misalignment of the navigation system with respect to the airframe. Specifically, there might be a small, uncompensated angular difference in how the navigation system is mounted compared to what roll and pitch angles correspond to trimmed level flight. This has the effect that to fly level, the autopilot should command a nonzero roll angle, which only can be achieved with a zero cross-track error if the integral term in Eq. 7 is nonzero. In Eq. 7, the integral term accounts for the error between the actual course χ and the integral-free desired LOS-angle.
To ensure modularity of the system, and applicability to a wide variety of autopilot interfaces, the guidance controller set-point should be formulated as a desired position. For the lateral axis, this is achieved by considering the desired course χ d as the direction of the vector from the UAV to the lookahead point p n look , of length y 2 e + z 2 e + Δ 2 , see Figs. 3 and 4, it is clear that the desired lateral position p n h,look = x h,look , y h,look , z h,look is found from the UAV position by where R * is the rotation matrix representing rotation about the * -axis, and where γ d , z e and γ p are defined in Eqs. 12, 10 and 13. By making similar geometric considerations in the longitudinal plane, an analogous longitudinal LOS guidance law can be formulated as [48] where the longitudinal cross-track error z e and the flight path angle of the line segment γ p are given by and where Δ v is the longitudinal lookahead distance.
To ensure modularity, the desired flight path angle is  (10). The UAV still aims at a point a distance Δ v ahead of the projection p n p = x p , y p , z p , but considers the projection point to be on the the vector l n = x n k+1 − x n k , which represents the line segment that the UAV is tracking, directly above or below the UAV p n UAV . Now, the height error h e is vertical, as illustrated in Fig. 4, in contrast to the longitudinal cross-track error from Eq. 10, which is orthogonal to l n .
From the vertical component of the projection point, where · represents the dot product, and where subscripts h and v indicate the horizontal and vertical components, respectively, the vertical lookahead position is computed as Similarly to Eq. 7, to account for possible steady-state vertical errors, the height component of Eq. 14 is extended with an integral term where h e = z p − z UAV . To make the guidance performance similar both in downwind and leewind, both the lateral and longitudinal lookahead distances should be functions of the ground speed, i.e.
where Δ t , Δ v,t are constant, tunable lookahead-time parameters, and where V g is the estimated ground speed. The longitudinal lookahead time, Δ v,t , can be considered as a compensation for the response of the UAV, including communication delays and time constants in lower-level controllers and reference filters. The guidance laws (8) and (10) can be implemented through different interfaces to the autopilot. As a consequence of the modular design goals, and under the assumption that all autopilots provide an interface to receive position references, the presented solution simply send the aggregate of the lateral and longitudinal lookahead points, p n look = x h,look , y h,look ,z v,look , , to the autopilot. However, if the autopilot provides an interface to receive e.g. desired course angle, desired flight path angle and desired airspeed, then χ d and γ d from the Eqs. 8 and 10 can be used directly. Furthermore, if an interface that accepts desired roll angle, desired pitch angle and desired throttle, these values can be calculated on the basis of χ d , γ d and airspeed error [48,49]. The lower-level control, regardless of the interface, is assumed provided by the autopilot.

Recovery Prediction and Detection
To avoid damage or entanglement in the arrest system, the motor should in some cases be stopped before it hits the arrest system. For a fixed-wing UAV in puller configuration, the propeller is the first thing that hits the arrest system, which forces the motor stop to be triggered by distance to the arrest system, not by impact detection. This implies a small risk of missing the arrest system while also deactivating the motor, which is mitigated by a starting a watchdog timer. If no impact is detected briefly after the deactivation of the motor, the recovery is deemed unsuccessful and the motor is re-activated, if possible. For an UAV using an internal combustion engine without a starter motor, reactivation in-air would not be possible and an alternative would be to set the engine to idle before recovery, although this could lead to propeller entanglement. Upon detection of impact the motor is disarmed. This impact is detected based on the longitudinal acceleration of the UAV, which is typically 5 − 10g during impact.

Operator Interface
Generally, an increased level of autonomy decreases the requirements to the user interface for the operator. To allow for automatic recovery, the operator interface should let the operator initiate the recovery, while also enable performance monitoring and possibly intervention. This requires radio communication, such that the UAV and arrest system can report their states, and a user interface that displays the essence of this information, including crosstrack errors, as a performance metric of the guidance controllers, desired values for the control, motion of the arrest system, the status of any automatic abort monitors, described in Section 2.5.1, as well as the ability to abort the landing.
There are many COTS UAV flight management graphical user interfaces (GUI) available that are used during normal UAV operations, and it is an advantage if the same interface is used in the recovery, as long as the recovery-specific requirements are met.

Aborted Recovery Framework
If the operator initiates abort, an emergency plan is executed. This is a simple dynamic plan, designed by the operator, that consists of a series of waypoints and a loiter, positioned relative to the current position of the arrest system. Thus, initiation of the emergency plan should bring the UAV to a loiter in a safe location, regardless of how the arrest system has moved.
In addition to being triggered by the operator, different abort triggers, that monitor different situations automatically, are implemented to relieve the burden on the operator. Examples of such situations, that make recovery impossible or highly risky, are Loss of radio communication or loss of arrest system pose measurement making it impossible for the UAV to know the pose of the arrest system.
Severe weather conditions such as strong and/or unpredictable wind, increase the risk involved with recovery. A coarse wind estimate, e.g. [50], is typically monitored by the UAV autopilot, or can be implemented separately.

Poor recovery performance
The ultimate objective is to hit the arrest system, so the system predicts if this is not achievable. This is monitored by the UAV by considering its cross-track errors.
Large relative speed from e.g. a strong tail wind can lead to high impact that jeopardizes the structural integrity of the UAV. This is monitored by the UAV, by comparing its own ground speed by that of the arrest system.

Missed catch
If the UAV passes the arrest system without registering a catch, its state is undefined, so the emergency plan is started.
However, not all situations allow for an abort [5]. Therefore, the abort framework also acknowledges the UAVs state severity level. This level is increased by another set of triggers e.g. if the UAV is too close to the arrest system to make a successful emergency maneuver, or if the fuel or battery is running so low that a go-around is impossible. An elevated state severity level causes the UAV to over-ride aborts, and continue the recovery regadless of some risks.

Implementation
To evaluate the arrest recovery control system architecture, the system was implemented for net recovery on a ship. A net was chosen since it occupies little space on a ship deck, which is the landing site of primary interest. Ship decks tend to be crammed, and recovery nets can be removed when not in use. Nets can also be held off the side of the ship by a crane, further reducing the space requirements and risk to the ship. The following subsections describe how the generic arrest recovery control system architecture from Section 2 is implemented for the specific scenario of net landing, and what adaptations have been made to accommodate a specific autopilot software and hardware.

Net Hardware and Software
The components of the net instrumentation are pictured in Fig. 5 and illustrated in the upper left part of Fig. 6. Both the base and the rover GNSS receivers are U-blox ZED-F9P, which are multi-constellation (configured to use the four global systems GPS, Galileo, GLONASS and BeiDou), multi-frequency receivers with built-in Real-timekinematic (RTK) processing. The first UART connection of each receiver is configured to send position and velocity estimates to a SenTiBoard sensor interface and timing board [51] at 5 Hz rate, while the second UART is used for a RTCM3 correction data stream also with a rate of 5 Hz, needed for RTK. The only difference in configuration between the receivers is that the base outputs RTCM3 data on the second UART, while the rover uses it as an input. The base receiver sends the correction stream to a BeagleBone Black (BBB) single-board computer, which is set up to distribute this on the network using a TCP server, and to the rover receiver of the net over UART. The SenTiBoard sends the received estimates to the BBB over USB for processing. On the BBB the position data is parsed, translated into net center position and heading according to Eqs. 3 and 1. This is implemented as a task in the DUNE Unified Navigation Environment robotic middleware framework of the LSTS Toolchain [52], while the resulting net position and heading, are distributed over the network in terms of Inter-Module Communication (IMC) [53] protocol over UDP.

UAV Hardware and Software
The UAVs used in the experiments use ArduPlane 3.9.9 [42], running on a Pixhawk autopilot hardware in the X8 UAV, and on a Pixhawk 2.1 for the Dolphine UAV. The rest of the landing-specific payload is common to all the experiments, and is illustrated in the upper right of Fig. 6. In both situations, the autopilot is connected to a Ublox ZED-F9P GNSS receiver, that is used to aid its INS, and to both an ethernet switch and an Odroid XU4 single board computer over UART, to send and receive Mavlink telemetry data. The GNSS receiver receives the correction data from the net base receiver, through the network, via the Odroid, into the receivers second UART port. The GNSS receiver onboard the UAV essentially has the same configuration as the net rover receiver, but outputs a few other messages required by the autopilot.
In order to maintain consistent altitude estimates which are comparable between the UAV and the net, the UAV cannot rely on the internal barometer alone, which is the default behaviour in ArduPilot. The barometer is calibrated Fig. 6 The different subcomponents of the UAV, the ground station and the instrumented net, that are relevant for the recovery Fig. 7 Block diagram of the UAV control architecture. Each block within DUNE roughly corresponds to a separate task, with IMC messages being passed between them once at the time of launch, but the ground level pressure can change during a flight, leading to drift in the altitude estimate. In order to avoid this problem, ArduPlane is set to use the height from the RTK GNSS receiver as the primary altitude sensor.
The Odroid also runs DUNE, which includes the net motion prediction, plan generation, guidance, and interface to the autopilot using the MAVLink protocol, in addition to publishing the state of the UAV and net recovery system as IMC messages over UDP, making it available for the Neptus GUI (see Section 3.3).
The recovery plan, as described in Section 2.1, is generated upon request by the operator, according to the parameters, start location, and the location of the recovery system. While the transit phase is static, based on the initial estimate of the landing location 1 and heading, the remainder of the plan is dynamic, and will update as the UAV receives position updates from the net. As the heading of the arrest system has a significant effect on the location of the endpoint of the transit phase, which is static from the time it is generated, it is assumed that the heading of the arrest system does not change significantly during the transit phase. This is reasonable for short, ship-based recoveries, under the assumption that the ship will either be in transit, with a clearly defined heading, actively kept stationary, using dynamic positioning, or slowly drifting. To some extent, an increased uncertainty in the yaw motion of the arrest system can be accounted for by increasing the length of the final alignment stage. For simplicity, the Dubins path, which is computed using the Dubins path library provided in [54,55], is represented as a sequence of waypoints. This makes the path piecewise linear, and thus not flyable according to [56], but by adjusting the parameter that sets the distance between the points, the performance is sufficient for this application. After it has been generated, the plan is stored in the plan database, see Fig. 7, and may be inspected by the operator. Upon initiation of recovery, the plan is loaded into the plan engine, which tracks the progress of the plan, and divides it into separate maneuvers. Each of the static waypoints of the transit phase are represented as a single maneuver, while the dynamic waypoints of the remainder of the plan is its own maneuver. Upon completion of one maneuver, the plan engine starts the next maneuver, by sending it to the maneuver handler. For static waypoints, the desired location is sent directly to the ArduPlane lateral L 1 guidance [57] and longitudinal TECS guidance [58] controllers, operating in GUIDED-mode. In AUTO-mode, the L 1 lateral guidance controller already supports line following. However, it is limited to static lines. So to achieve line following of dynamic lines, like the virtual runway, the ArduPlane guidance controllers are fed a desired location and an airspeed that is continuously updated by the Fake LOS block in Fig. 7.
Based on the current position of the net, and the UAVs progression along the dynamic part of the plan, the Fake LOS block calculates the desired destination for the UAV  20 to 150 m p offset 0 to 10 m in each axis p start (Geodetic) start position of the recovery plan Fig. 8 The recovery plan generation GUI, with the start position (blue), the arrest system (white), the UAV (green) and the plan inbetween. The small black circle ahead of the UAV corresponds to the carrot point, while the dynamic plan is not in the map view based on Eqs. 8 and 10. However, when in GUIDEDmode, ArduPlane interprets a desired location as "go here, then loiter". As a consequence, when horizontally close to the desired location, closer than the distance set by the parameter LOITER RAD, the UAV will turn to one side and start a loiter. To avoid this, LOITER RAD is set low, and the horizontal components x h,look and y h,look of the desired location p n look are extended in the direction χ d to form a carrot point p n carrot for the UAV to follow, when combined with the original desired heightz v,look , see Fig. 3. Essentially, the Fake LOS block transforms the desired position interface into a desired course and height interface.
The carrot point p n carrot from the LOS guidance is converted into a WGS84 reference, consisting of latitude, longitude and height, before it is passed to ArduPlane. As ArduPlane does not do line following in this setup, the integral effect in the L 1 guidance controller is disabled. To reduce the need for the integral term in Eqs. 7 and 15, it is advantageous to precisely determine the correct attitude misalignment of the autopilot, and account for this in the AHRS TRIM X and AHRS TRIM Y parameters to reduce the cross-track error.
From the desired height, and the desired airspeed, the ArduPlane TECS guidance controller calculates the desired pitch angle and throttle command based on the energy balance. 2 One important parameter is TECS SPDWEIGHT, which weighs the importance of speed tracking against the importance of altitude tracking. During recovery, altitude tracking becomes relatively more important than airspeed tracking, compared to normal flight, so TECS SPDWEIGHT is set to zero. In this configuration, airspeed is controlled by the slow throttle dynamics, while altitude is controlled by the fast elevator dynamics. Another important adjustment to TECS is to set GLIDE SLOPE MIN to zero. By default, ArduPlane smooths all jumps in altitude that are larger than this value, so by setting it to zero DUNE is given greater authority and less delay. In addition to these parameters, the L 1 and TECS controllers, and the lower level pitch and roll controllers, should also be tuned for a fast response, to compensate for rapid movement of the arrest system.
The recovery detection of Section 2.4.1 is implemented as a separate task in DUNE that subscribes to the distance to the net. Once this value is below a threshold, the ArduPlane parameter THR MAX is set to zero, effectively cutting the electric motor. The threshold is set to be dependent on the speed of the UAV relative the net, to be invariant to wind. When setting this threshold, communication rates from the net to the UAV should be considered, so that Fig. 9 The GUI recovery profile plugin, illustrating the net (here drawn with a size of 5 by 5 meters), current UAV position relative the path consisting of the errors y e and z e (red dot), predicted net impact point (blue dot) and current position in a NED-frame rotated around the z-axis to align with the net heading (green dot). The red cross marks the net impact point of the latest completed recovery Fig. 10 The arrest system approach path visualization plugin, illustrating the segments of the approach path, as well as the current UAV position p n UAV (red dot) and the carrot point p n carrot sent to the autopilot (green dot). Because of the integral effect in Eq. 7, the horizontal component of the carrot point does not have to lie on the line segment even if the cross-track error is zero. Similarly, the carrot-point height does not have to lie on the path due to differences in longitudinal and lateral lookahead distances, and lateral carrot point extension. In order to better show the errors in height and in cross-track, these are scaled independently of the horizontal distance towards the net, filling the available window space. The left side shows a vertical profile of the path, with grid marks with 100m spacing in the horizontal and 25m in the vertical direction. The right side shows a horizontal plane view, with grid marks with 4m spacing sideways and 100m in the direction towards the net. The arrest system, exemplified by a net, was rotated after the plan generation, to also show the lateral changes the motor is stopped before the net impact even with slow communication.

Ground Station Software
In this prototype implementation, Neptus [59] was chosen as the basis for an arrest system recovery GUI module. Neptus is the ground station component of the open-source LSTS Toolchain, allowing communication with DUNE using the IMC protocol. Specially made plugins provide two main features. First, the operator is able to decide the parameters that are used when the recovery plan is generated. This includes -selecting the starting point for the recovery plan, or select that it should start from the current UAV position, -select the desired recovery system, which enforces the UAV to only receive arrest system position messages from the selected recovery system, -the different distances and angles illustrated in Figs. 1 and 2, with typical values given in Table 1.
This interface also presents the generated plan to the operator, to allow validation, see Fig. 8. Secondly, the GUI contains a display where the operator can monitor the progress of the UAV along the recovery plan, including cross-track errors and a prediction of where the UAV would hit the arrest system given its current position, course and flight path angle, see Figs. 9 and 10. Neptus also includes a button that will abort the recovery attempt.

Experimental Validation
Initial verification of the software running in DUNE during development was performed using simulation, with Ardupilot running as software-in-the-loop on a laptop and the net position and attitude coming from a simulated vehicle in DUNE. In simulation the net was tested both as stationary and moving, with playback of logged position and attitude from a seismic support vessel motion reference unit providing realistic movement. Two physical experiments are described in this section. The first demonstrates the  Fig. 13 The position of the UAV when impacting the net, for all 43 attempts in a stationary net, as seen into the net from the approaching UAV placed on a barge, towed behind a moving ship. The two tests also use two different airframes, to demonstrate the flexibility of the system. The first test used a Skywalker X8 styrofoam flying wing UAV with an electric motor and a pusher propeller, see Fig. 11a, that has a wingspan of 2.1 m, a takeoff weight of about 3.5 kg, and cruise speed of 18 m/s. The second test used a Maritime Robotics Dolphine, see Fig. 11b, with an electric motor and a puller propeller, elevator and ailerons. Its wingspan is 1.8 m, the takeoff weight is 9.3 kg, while its cruise speed is 26 m/s. The airframe, actuators and autopilot hardware of the two UAVs are different, while the hardware that the recovery software runs on is simply moved from one UAV to the other, which illustrate the modularity of the system. The same net instrumentation is used in all the experiments.
During both the experiments, the UAV and net are connected to a ground control station over a data link based on Ubiquiti Rocket radios, using the AirMax  Fig. 6, consists of two computers; one running Ubuntu Linux and another running Windows 10. The Linux computer runs the Neptus ground control station, with the recovery GUI, which is used to visualize information and to interface the payload on both the UAV and the net. The Windows computer runs MissionPlanner, the ArduPlane ground control software, which is used as a backup for the Neptus GUI for communication with the UAV. In addition to communicating with the UAV using Mavlink messages over UDP, the Windows computer also communicates using a 433 MHz telemetry radio, for  redundancy. The Mavlink messages are then fused using MavProxy.

Experiments with Stationary Net
A preliminary test of the system with stationary net instrumentation, but without a physical net catching the UAV, was performed with the X8 UAV shown in Fig. 11a. This allowed looping the recovery plan to perform multiple recovery attempts in a single flight with lower risk. 43 recovery maneuvers were performed with a 220,m long approach with 9 • glideslope and a 190,m long final alignment with a 4 • glideslope. Winds were calm without significant gusts. The position of the UAV for all attempts are shown in Fig. 12. The top plot showing the sideways movement of the UAV indicates weak oscillating motion which could be caused by too high integral gain or too short lookahead distance in combination with time delays in the communication between the UAV and DUNE. 3 The position where the UAV would have impacted the net is depicted in Fig. 13, which shows a tendency to hit slightly below the target, but no clear tendency sideways. This is also supported by the average impact position, as reported by performance statistics in Table 2.

Experiments with Moving Net
To test the arrest recovery system in a more challenging and realistic environment, the net was mounted on a barge, towed behind a ship, depicted in Fig. 14. For these experiments a modified net rig with telescoping poles and fixed antenna mounting points was used, to simplify the mounting on the barge. The barge is about 8,m wide and 5,m long. When towed by the ship, it has a maximum speed of about 2.5 m/s. By adjusting the ropes used in the towing, the angle between the net velocity vector and heading can be adjusted, to test different scenarios. 4 An overview of the different scenarios used in the 15 recoveries of the Dolphine UAV made in the barge-mounted net is given in Table 3, which lists the horizontal and vertical error in the point of impact, as seen from the UAV flying into the net, for the different recoveries. All the scenarios use an approach of 225,m at a flight path angle of 7 • downward, while the final alignment is 225,m long, descending with 3 • . To illustrate the environmental conditions for each recovery attempt, the speed of the net and its relative direction, as well as the wind speed and direction relative the net, are also given. In recovery 4, a yaw motion of the net of approximately 0.5 • per second was initiated approximately 40 seconds before impact, meaning the UAV had to correct its approach course by 20 degrees while approaching the net. The same yaw rate was initiated approximately 20 seconds before impact in recovery 5. In recovery 15, the net was yawed by 5 degrees over a 10 seconds period starting 18 seconds before impact, then yawed back again before impact.
All the points-of-impact are plotted in Fig. 15, where the numbers correspond to the recovery attempt number given in Table 3. The vertical and horizontal trajectories of the UAV as it approaches the net are seen in Fig. 16, where the trajectories have been rotated by ψ arrest around the downaxis to ease the comparison. As the trajectories in these figures are relative to the net, some of the error can be attributed to the movement of the net. This is particularly true for the recovery attempts with large sideways velocity, as only the approach and the final alignment stages utilize the prediction of the ship motion. This is materialized as a larger initial cross-track error to the right of the path, as the barge and net are moving to the left while the start point of the approach phase is fixed when the plan is generated, J Intell Robot Syst (2021) 103: 73 and is not considering net motion afterwards. The crosstrack error in the final alignment phase for the recovery attempts with a large sideways velocity or yaw rate seem large and to the left of the path, as Fig. 16 consider the error relative to the actual position of the net, while the UAV aims at the predicted position for the time of impact. As the UAV approaches the net, these errors approach zero, as the predicted positions approach the actual positions. However, due to some communication delays that are not accounted for in the net motion prediction, the impact of the UAV ends up to the right of the net center, as it is lagging slightly behind the net. Furthermore, the simple net motion prediction does not account for any rotation of the net, which causes a larger error in scenarios 4, 5 and 15, where the a yawing motion was performed by the barge. In the straight approaches, the communication delays will also cause the UAV to believe that the net is closer than what it actually is, as the net has moved slightly during the communication delay. This could explain some of the height error. Another small contribution to the height error is the power-off of the motor before the impact. From the vertical position it would seem like there is a large error in the approach phase, ending 225,m before the net, as most of the trajectories approach at a much lower angle than the dashed line. This, however, is simply an artifact caused by the forward motion of the net, and the stationary Dubins path. As the net moves forward, the virtual runway moves with it, while the end of the Dubins path remains fixed. This causes the descent of the approach phase to be more gentle. As the height error seems systematic, it could possibly have been reduced by increasing the height integral effect or directly compensated for.
It is noted that the wind in Table 3 is based on the autopilot wind estimate, which is believed to give a reasonable representation of the average wind conditions during the approach and final alignment stages, but is not fast enough to accurately estimate wind gusts. From the results, there is no clear tendency in how this average wind affects the impact error, which is reasonable given the course-based guidance, and it is believed to be dominated by the effects of the communication delays. An example of this is the similar recoveries 7, 13 and 14, where the larger impact error in recoveries 13 and 14 are attributed to the larger sideways velocity of the net.

Discussion
The results show that the presented recovery system is able to reliably recover the UAVs in an arrest system of a size that would fit on many ships, in the tested environmental conditions which had even winds without significant gusts, and small waves. A test on a ship in more challenging conditions would give better understanding of the limits of the system and the net size required to cover all reasonable flight conditions.
Industrialization of the proposed architecture would require changes to increase its robustness to equipment failure. Software or hardware failure of the computer running the recovery software or the serial communication link with the autopilot is not handled in the implemented system, as the autopilot mode used is intended for single "go here, then loiter"-behaviour, not inputs at a fixed rate. A loss of position input is therefore not considered a failure, although it could lead to unfortunate situations in our case, with the UAV starting a small loiter around the position last received. This could be mitigated by extending the autopilot to include a watchdog that triggers a pre-defined action in the event that it stops receiving setpoints.
In a case where the arrest system can move and yaw significantly during the transit phase, the transit phase should be made dynamic. Re-planning of the transit could be done either continuously or if the arrest system movements pass set thresholds.
The communication delays causing increased arrest system impact position errors should be compensated for by improving the timestamping and clock synchronization of the UAV and the net case computer, for example by using UTC timestamps from the GNSS receivers.

Conclusion
Two test campaigns, with two different UAV platforms, demonstrated the modularity, reliability and performance of the presented arrested recovery system, where the average error norm of 43 recovery attempts in a stationary net was 0.30 ± 0.14m, while 15 recoveries in a moving net had an average error norm of 1.10 ± 0.30m. Although the results are deemed sufficiently accurate for the presented setup, remaining error sources are mostly systematic, like the simplistic motion prediction and communication delays, were discussed, as correction for these will enable recovery of larger UAVs or use of smaller arrest systems.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons. org/licenses/by/4.0/.