Conversion of a Coaxial Rotorcraft to a UAV—Lessons Learned ^†

Abstract

A coaxial helicopter with a maximum take-off weight of 600 kg was converted to an unmanned aerial vehicle. A minimally invasive robotic actuator system was developed, which can be retrofitted onto the copilot seat of the rotorcraft in a short period of time to enable automatic flight. The automatic flight control robot includes electromechanical actuators, which are connected to the cockpit inceptors and control the helicopter. Most of the sensors and avionic components were integrated into the modular robotic system for faster integration into the rotorcraft. The mechanical design of the control system, the development of the robot control software, and the control system architecture are described in this paper. Furthermore, the multi-body simulation of the robotic system and the estimation of the linear low-order actuator models from hover-frame flight test data are discussed. The developed technologies in this study are not specific to a coaxial helicopter and can be applied to the conversion of any crewed flight vehicle with mechanical controls to unmanned or fly-by-wire. This agile development of a full-size flying test-bed can accelerate the testing of advanced flight control laws, as well as advanced air mobility-related functions.

1. Introduction

The CoAX 600 rotorcraft, developed by edm aerotec GmbH [1] in Geisleden, Germany, was converted to a remotely piloted drone via a robotic actuator system. The CoAX 600 is a coaxial helicopter with a maximum take-off weight (MTOW) of 600 kg. It has been designed according to the German ultralight (UL) rotorcraft standards [2] and has a UL-type certificate from the German ultralight association (DULV). It is a two-seater rotorcraft, fitted with mechanical controls. The conversion of this rotorcraft to an unmanned aerial vehicle (UAV) was accomplished by designing a minimally invasive robotic flight control unit, which was installed on the copilot seat. The system directly actuates the pilot inceptors and allows for the conversion of the manned rotorcraft to a UAV in limited time. Furthermore, the conversion can be reversed, since the original mechanical flight controls remain untouched. To the best knowledge of the authors, this paper (initially published at SciTech 2024 [3]) marks the first occasion that the details of such a modular flight control system, applied to a full-size rotorcraft in free flight, have been published. This approach is beneficial not only for the quick and reversible conversion of existing rotorcraft to UAVs, but also leverages the existing (already certified and tested) mechanical controls, which can be beneficial for acquiring a permit-to-fly from the aviation authority.

The advantages and use-cases of unmanned aerial vehicles of different weight classes and configurations in the civil and military contexts have become more evident in the recent years. Besides the low-cost, mostly multi-rotor drones, widely available to the public for photo- and videography, aerospace manufacturers have developed multiple UAVs with vertical take-off and landing capabilities for different applications. The Kaman Corporation was recently awarded for the development of a cargo UAV quadcopter [4]. The KARGO UAV is capable of transporting a payload of up to 800 lbs over 500 NM. Other manufacturers such as the Israel Aerospace Industry [5] headquartered in Lod, Israel have developed rotorcraft UAVs using the main and tail rotor configuration, capable of lifting up to a 180 kg payload with a top speed of 150 $\mathrm{k}\mathrm{m}/\mathrm{h}$. The K-Max helicopter with intermeshing rotors can be mentioned as a pioneer of unmanned helicopters designed for (external) cargo transport [6,7]. The intermeshing double rotor design is known to be more efficient than conventional main and tail rotor configuration when flight operations mostly consist of hovering and slow flight. In a more recent project, a Black Hawk helicopter was transformed into an optionally piloted vehicle (OPV) by Sikorsky Aircraft [8], headquartered in Stratford, CT, USA. Another example of recent rotorcraft UAV projects is the VSR700 by Airbus Helicopters [9], which is a 700 kg tactical UAV developed for the French Navy, also capable of ship-borne operations. The A160 Hummingbird [10], developed by Frontier Systems and, later, Boeing, is another pioneer of rotorcraft unmanned aerial systems (UASs), which broke the endurance (more than 20 h) and altitude records (30,000 ft) at the time of its introduction. The project was abandoned by the US Army in 2012. Frontier Systems, a company based in Irvine, CA, USA, which was later acquired by Boeing, initiated the development of the A160 Hummingbird and also designed the Maverick VTOL UAS [11]. The Maverick VTOL UAS was developed based on a Robinson R22 and was later used as a test-bed for the development of the A160 Hummingbird at Boeing.

Other relevant work includes the conversion of manned aircraft with mechanical flight controls to optionally piloted vehicles (OPVs). Reference [12] compares the characteristics of avionic systems for manned and unmanned aircrafts, and uses the optionally piloted DA42 [13] and the Sagitta fixed-wing UAV [14] research platforms to elaborate on the differences of flight control systems for the two categories.

In all of the projects mentioned above, the actuators are deeply integrated in the rotorcraft mechanical control system. The rotorcraft are either designed as unmanned systems from the beginning or the manned–unmanned conversion is a long process and not easily reversible. The idea of retrofitting a robotic flight control system with integrated avionics has been investigated before. In the ROBOPilot project [15], such a system was designed for and tested on a Cessna 172 aircraft. The system successfully demonstrated automatic flight. In another study, a robotic actuator system was mounted into an SVH-4 rotorcraft and was tested in a hovering platform [16]. No free flight of the helicopter was reported in this project. The control mechanism in the cockpit consisted of a multi-arm robot and additional mechanisms for controlling the pedals and the collective lever. This concept is similar to an Aurora Flight Sciences study [17], in which a multi-arm multi-purpose robot was retrofitted into a Cessna Caravan copilot seat and could successfully fly the aircraft.

Some of the UAVs mentioned above, such as the VSR700 [9] and Kaman Kargo [4], were conceived as products. However, the majority of the projects, such as the DA 42 OPV [13] and the Sagitta fixed-wing UAV [14] research platforms, were developed as research platforms to test new flight control systems and functions. The DA 42 OPV was used in Ref. [18] to test vision-augmented navigation systems for automatic landings. The AirSTAR program at NASA is another example of a UAV, developed as a test-bed for testing new flight control laws and avionic systems [19,20], mostly focused on the goals of NASA’s Aviation Safety Program. The CoAX 600 UAV (also referred to as CoAX 600 UAS) falls into this category as well. The full-size rotorcraft is a valuable asset suitable for testing novel rotorcraft flight control laws and modern avionics.

This paper details the engineering challenges that were faced during the conversion of the CoAX 600 to an unmanned system and their solutions, focusing on the following:

• Mechanical design of the robotic actuator system;
• Modeling and simulation of the robotic system and the development of an in-flight feed-forward inverse-kinematics robot control software;
• The system architecture of the onboard avionics systems;
• Testing and evaluation of the systems and functions, involving flight testing in a hover frame and free flights.

The robotic actuator system was developed in CATIA, and a multi-body model of the robotic actuator system, consisting of multiple actuators and nonlinear kinematics, was developed in Simulink, using the Simscape toolbox. The CATIA–MATLAB interface of Ref. [21] was used for this purpose. The multi-body simulation model was coupled with physics-based models of the actuators. The simulation model was utilized to develop an onboard robot control software to cancel the nonlinear kinematics of the control mechanism. The onboard robot control software needed to be simple, robust, and avoid complex or non-determinstic simulation software (such as multi-body simulations). Furthermore, linear low-order systems of the actuators were also estimated from the test data captured during flights on a hover frame. A system architecture consisting of aerospace-grade components was developed, which facilitates the unmanned operation of the rotorcraft in compliance with the relevant aviation regulations. It also enabled recording the flight parameters from a wide array of sensors installed on the rotorcraft.

The paper starts with the details of the mechanical design of the control rods and the choice of the actuators in Section 2 and continues with the development of multi-body simulations and the robot control software in Section 2.1 and Section 2.2. Furthermore, the architecture of the flight control system (FCS) is discussed in Section 3. Section 4 focuses on the conducted tests, in the lab, on the rotorcraft in a hover frame, and in free flight. Section 5.1 describes the identification of linear low-order systems of the actuators using hover-frame flight data. Section 5.2 discusses the dynamics of the gimbal-mounted rotorcraft in the hover frame. Finally, the conclusion section focuses on the valuable lessons learned from the process of converting the CoAX 600 to a UAV.

Each of the sections includes a discussion of the applied methods and their effectiveness in achieving the goal of the project, which is the reversible conversion of the manned coaxial rotorcraft to a UAS in limited time. The UAS is intended to be used as a test-bed for the development of flight control systems and functions and advancing rotorcraft technology.

2. The Control Mechanism—Hardware and Software

The robotic system consists of three separate mechanisms, which control the stick, collective lever, and the pedals. The stick motion is controlled by two servos sitting on top of the shortened stick in the orientation depicted in Figure 1. Simultaneous actuation by both servos is required for a linear motion of the stick in any direction, commanded by the flight control laws. This combined actuation is realized by the robot control software, which cancels the nonlinear kinematics of the mechanism.

The development of the mechanical control hardware and software was supported by a multi-body, multi-domain simulation model of the robotic flight control system, implemented in Simulink, based on the developed CAD models of the robot integrated in the rotorcraft. The robot control software generates commands for each actuator to realize the commanded flight controls. The actuator commands are computed using the inverse kinematics of the robotic system, which is integrated in the robot control software as multi-dimensional look-up tables (LuTs). The robot control software is described in Section 2.2 in detail. The LuTs, determined from the multi-body simulation model, were corrected with limited measurements on the integrated robot in the helicopter copilot seat.

The pedal and the collective lever are also each controlled by a servo, as depicted in Figure 2a,b. The nonlinear control kinematics in this case is also canceled with inverse-kinematics LuTs embedded into the robot control software. However, the LuTs are one-dimensional for the collective lever and the pedal and can be easily determined based on a multi-body simulation model and corrected using measurements on the real system.

The overall weight of the system (including the electronics and power systems) was comparable to an average human pilot. All of the four servos on the rotorcraft are of the type DA70, developed by VOLZ Servos GmbH. The mechanical levers were manufactured from aerospace-grade aluminum and stainless steel. High precision machining was utilized for in the manufacturing process, such that no backlash could be noticed in the robot joints. The dual-motor servos also include an anti-backlash function, which uses force-fighting between two motors to significantly reduce any backlash in the actuators to 0.1 deg or less. This section provides more details about the model-based development process of the robotic system, and its feed-forward controller. The electronic flight control system of Section 3 was used to control the rotorcraft via the robotic actuator system.

2.1. Design of the Robotic Control System and the Multi-Body Simulation

The robotic flight control system was developed in the CAD software CATIA V5 R20. The design needed to satisfy the following requirements:

• Covering the complete motion space of the cockpit inceptors;
• Avoiding singularities in the motion space;
• Meeting the actuation rate requirements;
• Satisfying the required forces needed for the control of the cockpit inceptors;
• The safe operation of the system, including the custom-designed parts as well as the selected norm parts;
• A compact and light-weight design that would fit into the limited space of the CoAX 600 cockpit.

A multi-body simulation model was developed based on the CAD models already in the early stages of the design and development process to ensure that the designed kinematics overall and each individual part fulfilled the requirements mentioned above. Furthermore, by augmenting the multi-body simulation model of the control kinematics with physics-based models for the actuators, the development of the actuators could be supported by providing requirements such as the expected torque, or deflection rates.

The toolbox ProSys (ProSys is not publicly released. The Institute of Flight Dynamics of TU Munich can be contacted for inquiries about using the software package) [21], developed at the institute of Flight System Dynamics of TU Munich, was utilized to set up the multi-body simulation model. ProSys can automatically import the system dynamic and kinematic information of a mechanism from CATIA into Matlab and set up a Simulink–Simscape model, if certain guidelines are followed in the development of the CATIA model, such as the mechanism being modeled as a DMU kinematics module. The imported data include the information about the system mechanical joints (type, position, and degree of freedom), as well as the mass, center of gravity position, and the moments of inertia of each part. The automatically generated multi-body simulation model does not have any actuation and is, by default, simulated only under the influence of gravity.

Simscape allows for each joint available in the multi-body model to be actuated. This function was used to actuate the mechanism using the joints that represent the connection of an arm to a servo. If the rotational motion is commanded at a rotational joint, the required torque to realize the commanded motion can be measured at the same joint. This interface was also utilized to couple the Simscape multi-body model with physics-based models of the actuators in Simulink. Figure 3 shows the coupling of the servo Simulink model with the revolute joint, modeling the connection of the collective servo arm with the servo shaft, as an example. As seen in Figure 3, the servo position commands generated by the inverse-kinematics software are fed to the actuator model. The “is” position of the actuator (${\delta }_{{\mathrm{Act}}_{\mathrm{is}}}$ in Figure 3) is used to simulate the motion of the joint. The moment at the joint due to this motion is measured and fed back to the actuator with a transport delay to avoid an algebraic loop. The hinge moment is computed by the multi-body simulation mainly based on the aerodynamic forces and moments, which are modeled as torsion spring and damping coefficients at the pilot inceptors. The Simscape multi-body simulation propagates these moments through the nonlinear kinematics of the system to compute the moments at the servo shaft. In addition to the aerodynamic moments, the inertia of the system parts also contribute to the total moment at the servos, due to their acceleration. The actuator Simulink models consist of its subsystems models, i.e., the electric DC motors (developed as described in Ref. [22]), the gearbox, the proportional–differential motor controller, and the electronics. The actuator models were parametrized based on the initial selection of the components during the design process. The multi-body simulation model, coupled with the actuators, conclude the simulation model for the forward kinematics of the robot.

The same auto-generated non-actuated model was used to develop a model for the inverse kinematics of the robot. In the inverse-kinematics subsystem, the joints representing the position of the cockpit inceptors (cyclic stick, collective lever, and the pedal) were used for the actuation of the multi-body simulation model. The revolute joints at the respective servo shafts rotate according to the commanded cockpit inceptor position such that the boundary conditions of the kinematics are fulfilled. The motion of the revolute joints at the servo shafts was tapped and used as input for the servo models of the forward kinematics in the simulation. Figure 4 provides an overview of the overall simulation setup. It shows how the same auto-generated multi-body model was utilized to create the inverse- and forward-dynamics/kinematics models. The servo position commands going to the forward dynamics model, which also includes the actuator dynamics, were low-pass filtered, since jumps in the commands drive the linear algebraic system to a singularity.

The overall multi-body simulation model required a low integration time-step of 0.005 s to remain numerically stable. The model was integrated over time using the MATLAB ODE15 solver [23], which is suitable for stiff differential equations. The actual position of the cockpit inceptor joints, achieved with the actuation of the servos under load, as well as the moments acting on the servos, and the servo power usage, are provided as the outputs of the overall simulation model.

2.2. Robot Control Software

Each servo has its own position controller designed by the manufacturer VOLZ Servos GmbH, a company based in Offenbach, Germany. However, a feed-forward inverse-kinematics controller was needed to generate position commands for the servos, which would result in a specific position of a cockpit inceptor matching a blade pitch angle command generated by the flight control law. The simulation setup, presented in Section 2.1, already included the inverse kinematics of the robot. The complex Simscape model was, however, not suitable for deployment on a flight control computer. The simulation of such multi-body models in real time requires computational resources that exceed those of a typical flight control computer. Furthermore, solving such linear algebraic equations is not deterministic and the execution time is difficult to predict. Therefore, the inverse kinematics of the robot was integrated in the robot control software as one-dimensional lookup tables (LuTs) for the pedal and the collective lever, and two-dimensional LuTs for the control stick.

The stick LuTs were determined by simulating the inverse-kinematics multi-body simulation for a 45 × 45 uniform grid of the cyclic stick in equidistant longitudinal and lateral positions. The corresponding positions of the servos ${\mathrm{Act}}_{{\mathrm{Cyc}}_{\mathrm{C}}}$ (actuator 1) and ${\mathrm{Act}}_{{\mathrm{Cyc}}_{\mathrm{S}}}$ (actuator 2) were recorded during 2025 simulation runs of the multi-body simulation model at the 45 × 45 cyclic stick positions. Limited adjustment of the LuTs based on measurements on the real system were necessary due to the manufacturing tolerances and further inaccuracies in the assembly of the robot in the helicopter. The servo internal position measurements using a hall sensor and the angles of the control stick, measured by inclinometers, were used for the calibration of the LuTs. The selected longitudinal and lateral calibration points, as well as the full inverse-kinematics LuTs, are visualized in Figure 5 and Figure 6. The correction points were chosen arbitrarily along the lateral and longitudinal stick deflection directions, while attempting to achieve a uniform distribution of points in both directions.

A linear interpolation scheme was applied to the points of the 45 × 45 grid ${\mathit{\sigma }}_{{\mathrm{sim}}_i}$ for each actuator ($i\in \{1,2\}$), denoted by $\nu ({\delta }_{{\mathrm{stick}}_{\mathrm{long}}},{\delta }_{{\mathrm{stick}}_{\mathrm{lat}}},{\mathit{\sigma }}_{{\mathrm{sim}}_i})$, which can be evaluated at any stick position query point $[{\delta }_{{\mathrm{stick}}_{\mathrm{long}}},{\delta }_{{\mathrm{stick}}_{\mathrm{lat}}}]$ to determine the output shaft position of each of the actuators (${\delta }_{{\mathrm{act}}_i}$) required to achieve a desired stick position. The grid for each actuator consists of the vectors of the longitudinal and lateral stick positions at which the virtual measurements took place (${\mathit{\alpha }}_{\mathrm{long}}$ and ${\mathit{\alpha }}_{\mathrm{lat}}$), and the corresponding position of the servo output shaft ${\mathit{\delta }}_{{\mathrm{act}}_{i_{\alpha }}}$:

$${\mathit{\sigma }}_{{\mathrm{sim}}_i}:={\mathit{\alpha }}_{\mathrm{long}}\times {\mathit{\alpha }}_{\mathrm{lat}}\to {\mathit{\delta }}_{{\mathrm{act}}_{i_{\alpha }}},i\in \{1,2\}$$

(1)

The initial simulation-based uncorrected grid was evaluated at the measured stick positions to compute the error between the simulation-based grid and the longitudinal measurement points (the blue points in Figure 5 and Figure 6), denoted as $\mathit{\lambda }$:

$$e_{i_{\mathit{\lambda }}}={\mathit{\delta }}_{{\mathrm{act}}_{i_{\mathit{\lambda }}}}-\nu \left({\mathit{\lambda }}_{\mathrm{long}},{\mathit{\lambda }}_{\mathrm{lat}},{\mathit{\sigma }}_{\mathrm{sim}}\right),i\in \{1,2\}$$

(2)

where ${\delta }_{{\mathrm{act}}_{i_{\lambda }}}$ is the measured position of the stick actuators 1 and 2. ${\mathit{\lambda }}_{\mathrm{long}}$ and ${\mathit{\lambda }}_{\mathrm{lat}}$ are the longitudinal and lateral deflections of the stick at which the actuator position was sampled on the real system. The chosen longitudinal positions of the stick were commanded via the initial simulation-based inverse-kinematics grid as pure longitudinal commands. Therefore, any measured nonzero ${\lambda }_{\mathrm{lat}}$ is a result of the error in the inverse-kinematics grid. We can form a longitudinal error grid for each actuator with ${\mathit{e}}_{i_{\lambda }}$, and the sampling points $\mathit{\lambda }$:

$${\mathit{\sigma }}_{{\mathit{e}}_{i_{\mathit{\lambda }}}}:={\mathit{\lambda }}_{\mathrm{long}}\times {\mathit{\lambda }}_{\mathrm{lat}}\to {\mathit{e}}_{{\mathit{\lambda }}_i},i\in \{1,2\}$$

(3)

In a similar way, the grid error for the lateral measurement points $\mathit{\beta }$ (the red points in Figure 5 and Figure 6) is computed after the application of the longitudinal correction, using the above error grid ${\mathit{\sigma }}_{{\mathit{e}}_{i_{\mathit{\lambda }}}}$ of the longitudinal measurement points and the two-dimensional linear interpolation operator $\nu$:

$${\mathit{e}}_{i_{\mathit{\beta }}}={\mathit{\delta }}_{{\mathrm{act}}_{i_{\mathit{\beta }}}}-\nu \left({\mathit{\beta }}_{\mathrm{long}},{\mathit{\beta }}_{\mathrm{lat}},{\mathit{\sigma }}_{\mathrm{sim}}\right)-\nu ({\mathit{\beta }}_{\mathrm{long}},\mathbf{0},{\mathit{\sigma }}_{e_{i_{\mathit{\lambda }}}}),i\in \{1,2\}$$

(4)

The lateral measurement points can be collected together with their associated error to form the grid

$${\mathit{\sigma }}_{e_{i_{\mathit{\beta }}}}:={\mathit{\beta }}_{\mathrm{long}}\times {\mathit{\beta }}_{\mathrm{lat}}\to {\mathit{e}}_{{\mathit{\beta }}_i}$$

(5)

for the correction of the inverse-kinematics grids with respect to the stick lateral deflection measurement points. The feed-forward control law for each actuator becomes

$${\delta }_{{\mathrm{act}}_i}={\nu }_{\mathrm{sim}}({\delta }_{{\mathrm{stick}}_{\mathrm{long}}},{\delta }_{{\mathrm{stick}}_{\mathrm{lat}}},{\mathit{\sigma }}_{\mathrm{sim}})+\nu ({\delta }_{{\mathrm{stick}}_{\mathrm{long}}},0,{\mathit{\sigma }}_{{\mathit{e}}_{i_{\mathit{\lambda }}}})+\nu (0,{\delta }_{{\mathrm{stick}}_{\mathrm{long}}},{\mathit{\sigma }}_{{\mathit{e}}_{i_{\mathit{\beta }}}})$$

(6)

and is visualized in Figure 5 and Figure 6 for the actuators 1 and 2.

The one-dimensional LuTs for the pedal and collective lever were developed only based on the direct measurements on the system, as enough points in the motion space could be measured in the one-dimensional case. Figure 7 and Figure 8 show the mapping between the collective and pedal positions and their respective actuators. Nonlinearities are evident in all of the one- and two-dimensional mappings.

The structure of the robot control software is provided in Figure 9. The collective and cyclic commands, computed by the flight control law are converted to cockpit inceptor positions by a first set of linear one-dimensional LuTs. The LuTs of Figure 5, Figure 6, Figure 7 and Figure 8 are applied to the cockpit inceptor positions to compute the corresponding servo positions. The kinematics of the control system, specifically in case of the stick with two actuators, was successfully canceled via the approach described here, such that the lateral or longitudinal commands from the flight controller were executed as such on the pilot stick without any cross-axis coupling.

3. Flight Control System

This section describes the onboard flight control system (FCS). It starts with the operational concept and the requirements of the FCS, and continues with a description of the system architecture, and the remote crew interface. The section concludes with an overview of the validation steps taken for the FCS.

3.1. Operational Concept and Requirements

The concept for the FCS was driven by the intended application as an unmanned technology demonstrator for the robotic actuation system. The main required functions of the system are as follows:

• Manual remote control: during the system definition, it was decided to implement only manual control (feedback-augmented, and attitude law) in a first step in order to reduce the complexity for the demonstration flights. The manual remote control system also serves as a basis for a potential later extension with automatic flight control functions. In this case, fallback to manual control would provide an emergency procedure to mitigate malfunctions of the automatic flight control system.
• Telemetry data indication: the system must provide the capability for the remote crew to monitor critical system parameters in real time on the ground during operations.
• Remote flight termination: the possibility to remotely shut down the engine is required as a safety measure to ensure containment of the UAV within a predefined geographical volume, thereby reducing the risk to other airspace participants or third parties on the ground in the event of a control loss.
• Measurement data collection for post-flight processing: a wide array of sensors has been mounted on the rotorcraft, including two inertial measurement units at different positions, two GPS receivers, an angular acceleration sensor, and potentiometers and strain gauges at different positions along the control rods.

Additional safety objectives resulted from the application of the SORA (specific operations risk assessment, see Ref. [24], Article 11) process, which was required for the operational authorization of the rotorcraft as an unmanned aircraft system (UAS) by the German authorities. Following this process, objectives were defined based on a specific assurance and integrity level (SAIL). The SAIL is a qualitative measure that drives the objectives to be fulfilled by an applicant. It is defined based on an assessment of the risk of the UAS operation on the ground and in the air (for details refer to Ref. [24], AMC 1 to Article 11). As we chose to operate the rotorcraft over a so-called “controlled ground area” where access was restricted to members of the remote crew, operate only within visual line of sight (VLOS), and reduce the risk of encountering another aircraft by operating in an active aerodrome traffic zone (ATZ), which was exclusively used by the UAS, the operation was classified as SAIL II. In this context, two fundamental safety requirements are given by Ref. [24]:

• Containment: “No probable failure of the UAS or any external system supporting the operation should lead to operation outside the operational volume.” [24], p. 61;
• Safety and reliability: “The resulting hazards are minimized in the event of a probable malfunction or failure of the UAS.” [24], p. 109.

The first objective requires to contain the operations to a predefined, approved geographic volume and addresses the risk resulting from exceeding this operating volume as a result of a loss of control over the UAS. It should be noted that compliance with the second requirement is optional for SAIL II operations, but it was decided to use this as a governing principle for the system architecture design as far as practicable. As a basic design principle, fault tolerance against any single failure, unless it can be reasonably assumed to be improbable, was required for the presented system architecture as a result of this objective.

3.2. System Architecture

A schematic overview of the flight control system is shown in Figure 10. The aircraft is always—in all operating modes—controlled remotely by the remote pilot, using a hand-held remote control (RC). Furthermore, a second remote pilot can take over control using a backup RC. A ground monitoring unit (GMU) provides live indication of telemetry data. Onboard the air vehicle, two separate flight control channels process the commands received from the remote pilot: A primary flight control system (PFCS) provides active closed-loop control of the rotorcraft and additionally contains the equipment required for measurement data acquisition and the telemetry data link. The direct flight control system (DFCS) acts as a backup system and provides a direct control mode in which the commanded blade pitch angles of the lower and upper rotor and the rudder deflection are directly proportional to the control stick deflections on the remote control, without any artificial feedback loops. Each flight control channel has its own, independent power supply as well as its own set of receiver units to process radio control (RC) signals. Most of the main components of the system ran with a sampling rate of 50 Hz. The flight data recorder could log signals with a sampling rate of up to 1 kHz.

A separate dual-channel control unit (APCU) executes the robot control software and translates the flight control commands into direct servo deflection orders. The electromechanical servos feature a duplex design, where the output shaft is driven by two electric motors that are combined using a torque summing gearbox. Each electric motor is driven by its own motor control unit, which is connected to one of the two APCU channels.

The detailed electronic architecture is shown in Figure 11. The remote-control functions are executed on two control units: The flight control computer (FCC) provides closed-loop attitude and angular rate control. The inertial measurements for these control functions are captured by an air data attitude heading reference (ADAHRS) unit. It should be noted that no air data measurements are used for closed-loop control. The backup direct mode control is executed by the so-called “Pilot-DCU” (PDCU). Each control unit receives command signals from the RC through multiple receiver units (called PRX in Figure 11). The receiver units are placed on different locations outside the helicopter fuselage to ensure stable reception on multiple units in any orientation of the helicopter. A cross-talk interface between the PDCU and FCC additionally forwards the control commands received by the PDCU to the FCC such that the augmented control through the FCC remains available even if reception is lost on all of the directly connected receiver units.

The fallback to the DFCS is implemented by a simple priority selection logic on the actuator control unit: In normal operating conditions, the PDCU is passive and the FCC is in command. Whenever the PDCU is transmitting commands, the PDCU commands are selected by the APCU channels. The PDCU can be activated either manually (using dedicated switches on the RC) or automatically, when a loss of commands from the FCC is detected. For this purpose, the actuator control unit monitors the periodic reception of control commands from the FCC and forwards the reception status to the PDCU.

Additional sensors are included for data recording and telemetry: A GPS receiver (GNSSU) provides the 3D position for monitoring the containment of the UAV with respect to the boundaries of the operating volume on the ground. An additional inertial measurement unit (BSB) with an integrated GPS receiver provides rate and acceleration data and a second GPS position for post-flight processing. The omega-dot sensor (ODS) measures angular accelerations. A data concentrator unit (SDCU) forwards these measurements on a common digital data bus. The SDCU also acquires discrete signals that drive the warning LEDs that are normally used to indicate engine warnings in the manned version of the helicopter. The AOX unit acquires the analog signals from a cardan-mounted combined angle of attack/angle of sideslip probe that is located on a boom.

A central data acquisition unit (DAU) captures and records measurement data from all connected devices and forwards telemetry data to the modem for transmission to the ground station. It is also connected to the helicopter’s engine instrumentation; another data acquisition unit (DAQU) provides measurements of rotor and motor RPM, oil pressure and temperature, and other engine parameters. In the manned version of the helicopter, these parameters are provided to the pilot on a display unit (EMSIS) in the cockpit. For the unmanned version, the same parameters are forwarded to the ground, where an identical display unit is mounted in the ground monitoring unit (cf. Section 3.3).

The containment requirement is addressed by a separate flight termination system, which, completely independent from the FCS, allows to remotely shut down the rotorcraft combustion engine by interrupting the power supply to its ignition circuits. The system uses a separate data link for the transmission of the termination trigger from a ground unit (FTS-FTU) to the airborne receiver (FTR). It is developed to the RCC-319 standard [25], which is based on a robust analogue tone-based modulation of the transmitted command signal. In order to avoid disturbances from interfering with RF signals, the data link uses a restricted frequency band that requires authorization by the German telecommunications authority.

3.3. Remote Crew Interface

The remote crew interfaces are shown in Figure 12. Two identical commercial hand-held remote-control transmitters are used for the manual control of the rotorcraft by the remote pilot (cf. Figure 12a). This RC system was selected due to its redundant data link (each transmitter provides two 2.4 GHz modules and a backup 900 MHz module) and its wide application in the RC model community. In addition to the four main control channels for roll, pitch, yaw, and collective control, buttons on the RC are used to select the operating mode of the onboard flight control system. The two centrally located “TAKE OVER” buttons allow to take over the control through the backup RC in case of a control malfunction.

A ground monitoring unit (cf. Figure 12b) provides real-time indication of flight critical system parameters such as the voltage levels of the FCS batteries and the signal strength of the different data links on a main indications panel. This panel also includes an indication of the position of the UAV over a synthetic map view, together with the boundaries of the operating volume. The engine warning LEDs that are installed in the manned version of the helicopter are replicated by software lamps. The panel also includes synoptics sections showing the current operating mode of the flight control system, which are used mainly to provide feedback to the remote pilot during operations and for troubleshooting. Engine parameters and the current fuel level are indicated on a separate display unit (EMSIS), which is identical to the indication unit normally installed in the cockpit of the manned version of the helicopter. Therefore, all indications and warnings according to the aircraft flight manual of the manned variant are also provided in the unmanned version.

3.4. Validation

The system architecture design and functions were validated in an integrated system simulation environment that included the design models for the FCC, PDCU and APCU control software, the GMU display software, sensor models, emulators for the two RCs, and the complete digital communication architecture. This integrated system model was developed from a centralized description of the logical transport layer and physical interfaces of the system architecture and stored in a machine-readable database format, as described in Ref. [26].

Due to the time and budget constraints of the project, an exhaustive requirements-based testing of the FCS equipment and the integrated system was not performed. Instead, test cases were derived based on operational sequences that describe the intended system behavior under nominal conditions as well as in failure conditions. This principle is further described in Ref. [27]. Those sequences were used to define test cases that test the system behavior in the integrated simulation environment, as well as in hardware-in-the-loop (HIL) tests and ground tests of the integrated system.

Additionally, dedicated ground tests have been performed with the fully integrated system in order to verify the effective range of the data links for remote control, telemetry data transmission, and remote flight termination. An overview of the HIL tests as well as system tests in a hover frame are provided in the following section.

4. Testing and Evaluation

Besides software tests of the system discussed in Section 3.4, and the model-in-the-loop tests of the flight control laws discussed in Ref. [28], the following tests were carried out involving the original system hardware:

• Hardware-in-the-loop tests of the system including the actuators, mounted on a stationary frame of the rotorcraft in the lab;
• Tests of the system and flight software on an electric version of the CoAX 600 mounted to a hover frame, which restricts the motion of the helicopter;
• Flight tests of the CoAX 600 UAS at the Magdeburg–Cochstedt airport.

The same robotic control system with its integrated avionics was used in all of the three test setups on three different rotorcraft. The modular nature of the system allowed the rapid integration of the system into each of the test rotorcraft. These test and validation steps are discussed in this section.

4.1. Hardware-in-the-Loop Testing

In a first step, the flight control robot was assembled on a stationary frame of the helicopter in the lab. The frame had all of the original dimensions and the included mechanical controls of the rotorcraft (cf. Figure 13). The concept, and the different functions of the robot were tested and validated in the lab. The setup was also used to tune the actuators’ internal position controller.

The test environment was extended by the HIL simulation of the helicopter. The simulation model of Ref. [28] was used for this purpose. The HIL tests included the simulation model, the flight control computer, the actuators, and the pilot, controlling the helicopter via a hand-held RC transmitter. The hardware setup can be seen in Figure 13, and the interaction of the different hardware and software components of the tests is visualized in Figure 14. The control commands from the RC are received by multiple receiver units, which forward the received command data to two control units (PDCU and FCC; for details, refer to Section 3.2). Depending on the active control mode, the unit in command computes rotor blade pitch angle commands, which are transmitted to a separate actuator control unit (APCU) running the robot control software. The servo position is measured by the integrated hall sensors and transmitted to the real-time PC running the simulation model. The simulation model consists of the flight dynamics of Ref. [28], models for the forward kinematics of the control system including the robot (mapping from servo positions to the rotor collective/cyclic pitch), as well as sensor models, among others, for the attitude heading reference system.

The HIL tests were also used for initial crew training. They were the first opportunity for the remote pilots to control the rotorcraft using the original hardware. It was observed that the pilots could not effectively operate the unmanned rotorcraft (model) when the time delays caused by the system and the actuator dynamics were considered. This is despite the fact that both the manned operation of the rotorcraft via its mechanical controls and the unmanned operation of the model without the system and the actuator dynamics were easily possible. The pilots could still avoid a crash, but with a heavy workload. This was further motivation for the development of the flight control laws of Ref. [28]. The flight tests were also designed such that the feedback controller was always engaged.

4.2. Testing in a Hover Frame

The robotic controller, including the electronic flight control system, was integrated into an electric variant of the CoAX 600 rotorcraft, which was gimbal-mounted into a hover frame (Figure 15), allowing for the rotation of the helicopter around the mounting point. The hover frame can also move on wheels, which allows for the translational motion of the rotorcraft, however, with significant wheel friction. The flight control robot and the electronic control system were exposed to the real-world helicopter flight conditions, with a rotating rotor in the hover frame, for the first time.

Besides performing system tests and crew training, which was reported in Ref. [3], the flight tests in the hover frame were used to gather data for the identification of linear low-order models for the robotic actuator system. Such simple linear models are essential for the stability and robustness analysis of the flight control laws, as described in Ref. [28]. The data were generated using automatic injection of doublet, sweep, and multi-sine maneuvers. This process is described in Section 5.1. Furthermore, the gathered data during the flight tests were utilized to analyze the flight dynamics of the rotorcraft in a hover frame (cf. Section 5.2). This was done to compare the flight dynamics of the rotorcraft in the hover frame with free flight and compare its suitability for testing the control laws on the hover frame besides avionics testing.

4.3. Flight Testing

The permit-to-fly for free unmanned UAS operation was obtained from the LBA via the SORA process [29] for the SAIL II operation in the visual line of sight (VLOS). The flight tests (c.f. Figure 16) took place at the Magdeburg–Cochstedt airport (EDBC), which is dedicated as a national test center for unmanned aerial vehicles in Germany. The flight volumes approved for operation are visualized in Figure 17. Three separate areas were cleared for flight, which are the three green overlapping areas of Figure 17. Due to the size of the airport and the limitation to VLOS flights, a bigger single volume could not be cleared for flight, since the aircraft visibility for the pilots might have become insufficient. The vertical extent of the approved flight volume was 50 m (140 ft) above ground. Besides the regular operation volumes (the green zones) on Figure 17, a contingency zone was planned, in which specific actions were to be taken to bring the rotorcraft back in the green area. Beyond that, an additional risk buffer zone was planned to account for unexpected factors not explicitly considered in the risk assessment.

The flight tests were performed in the attitude mode. One of the two pilots operated the aircraft while a second pilot was on standby and ready to take over in the case of an emergency. The ground crew monitored the flight parameters on a ground station, receiving the data from the aircraft via telemetry. The ground station crew maintained communication with the remote pilots via radio intercom. A test director maintained the communication with the airport tower. The helicopter had a flight termination system onboard, which was operated by a safety manager. The safety manager’s role was to terminate the flight on the pilot’s command in case of an emergency, such as a fly-away outside of the bounds of approved operating volume.

The rotorcraft was flown in hover and forward flight speeds of up to 7 m/s at a maximum altitude of approximately 20 m. The system and the flight control law performed as expected in this region of the flight envelope, for which the attitude controller was designed and tested. The helicopter with the closed-loop controller could also be operated on windy days with wind velocities up to 15 knots and significant gusts. The pilot could safely operate the helicopter under these conditions without a significant increase in workload. Manual doublets and frequency sweeps were injected during the flight tests to help assess the controller performance and improve it in the future. A total of four flight hours was accumulated during the test campaign. However, as seen in Figure 18, the pilots did not use the full extent of the available operation volume according to the permit-to-fly (c.f. Figure 17). It was difficult to perceive the attitude of the helicopter as its distance from the remote pilot increased. This was essential, since the rotorcraft was operated via an attitude control law. It can be inferred that a velocity controller is required for flying more complex missions in the future. Non of the degradation or emergency safety measures (e.g., the CFCS or the flight termination system) had to be used during the operation.

5. Analysis

The data collected during the hover-frame tests discussed in Section 4 were used to analyze two aspects of the system relevant for the development process and performing successful flight tests. Linear low-order models of the actuators were identified using the hover-frame data. Furthermore, the hover-frame test data were used to identify linear models of the gimbal-mounted rotorcraft motion.

5.1. Linear Low-Order Systems for the Actuator Dynamics

Linear low-order system models of the servos were needed for the stability and robustness analysis of the flight controller, as described in Ref. [28]. These linear differential equations provide a simplified representation of the dynamics between a commanded rotor collective or cyclic pitch by the flight control law (${\theta }_{{\mathrm{col}}_{\mathrm{cmd}}}$, ${\theta }_{c_{\mathrm{cmd}}}$, ${\theta }_{s_{\mathrm{cmd}}}$, ${\theta }_{{\mathrm{yaw}}_{\mathrm{cmd}}}$) to actual blade pitch angle, achieved by the actuators. The blades have a linear twist. Therefore, the pitch angle at the radial position of $r=0.7$, with r being the non-dimensional rotor radius, was chosen as the reference point for the blade pitch commands and measurements (c.f. Figure 19a).

This could be done by the linearization of the nonlinear model of the robotic system in Simulink/Simscape (cf. Section 2.1) and applying model-order reduction methods to achieve a linear low-order model representing the onboard actuation system. A fully simulation-based approach can, however, not account for all of the real-world effects. Therefore, specific tests were performed on the electric helicopter in a hover frame (cf. Section 4) to gather data for identifying the actuator models from flight data. A series of sine sweep and multi-sine maneuvers, as described in Ref. [30], were automatically injected during hover flights in the hover frame. The maneuvers were in the frequency range, in which the system eigenfrequencies were expected to be. The maximum sweep/multi-sine frequencies were limited by the 50 Hz sampling rate of the data acquisition system.

The true in-flight actuator responses were measured indirectly using four draw-wire potentiometers. The lower rotor pitch angles were chosen as the reference response to the cyclic and collective commands. The yaw command only affects the upper rotor. Three of the potentiometers were mounted onto the three control rods on the starboard and port sides, as well as the front of the swashplate. The fourth potentiometer was positioned on one of the control rods connecting the pedals to the upper rotor swashplate and the rudder. The rotor pitch angles at the $r=0.7$ position for different pilot stick settings were measured using inclinometers, mounted on each blade on the ground (with the engine off). The potentiometer readings were also recorded for each of these measurement points. The test was repeated for multiple azimuth angles and multiple settings of the cockpit inceptors to form a measurement grid. A linear function, relating the potentiometer readings to the lower rotor collective and cyclic pitch angles ${\theta }_{\mathrm{col}}$, ${\theta }_c$, and ${\theta }_s$, as well as the upper rotor additional collective for yaw control ${\theta }_{\mathrm{yaw}}$, was identified with the help of the least-squares regression methods [30]. This linear function was applied to the potentiometer measurements captured during the flight tests in the hover frame to reconstruct the rotor collective and cyclic pitch responses. Two of the draw-wire potentiometers and the measurement position of the ${\theta }_c$ and ${\theta }_s$ measurements on the lower rotor are visualized in Figure 19b.

The estimation of the actuator models took place in the frequency domain using the Matlab system identification toolbox. Three transfer functions $\mathsf{\Theta }=G_{\theta }{\mathsf{\Theta }}_{\mathrm{cmd}}$ were identified for the input channels ${\theta }_s$, ${\theta }_c$, and ${\theta }_{\mathrm{yaw}}$. It was observed that the data from the potentiometer on the swashplate front position were too noisy. This noise mostly affected the pseudo-measurements of ${\theta }_s$. Due to this extreme noise, the system identification results for the $G_{{\theta }_s}$ transfer function (for the longitudinal stick deflection) were poor. Therefore, only the actuator dynamic model for the lateral stick motion was used. Due to the mostly similar kinematics and based on the analysis of ground data, the assumption was made that the actuator dynamics in the stick longitudinal and lateral motion were similar ($G_{{\theta }_s}\approx G_{{\theta }_c}$). No actuator model for the collective lever was estimated, since this channel was not controlled with a feedback controller at this stage of the work.

First- and second-order linear model structures were tested for parameter estimation. Furthermore, a signal transport delay of 0.02 s was found in the data and considered in the model structure. The following first-order transfer function was estimated for the stick cyclic commands:

$${\mathsf{\Theta }}_{c/s}=e^{-0.02s}{\displaystyle \frac{19.37}{s+21.79}}{\mathsf{\Theta }}_{c/s_{\mathrm{cmd}}}$$

(7)

and the yaw actuator dynamics is characterized by the following second-order system:

$${\mathsf{\Theta }}_{\mathrm{yaw}}=e^{-0.02s}{\displaystyle \frac{661.4}{s^2+37.37s+654.4}}{\mathsf{\Theta }}_{{\mathrm{yaw}}_{\mathrm{cmd}}}$$

(8)

The stick actuator has a single pole at 21.8 $\mathrm{rad}{\mathrm{s}}^{-1}$, and the pedal actuator has a stable pole pair at 25.6 $\mathrm{rad}{\mathrm{s}}^{-1}$, with a relative damping of $0.73$. The poles can be seen in Figure 20. The model fit in the frequency domain can be seen in Figure 21. It can be seen that the stick actuator model shows a constant phase shift with respect to the data. This points to the existence of backlash in the system.

The identification of the actuator models was made difficult by the low sampling rate of the data, and the amplitude of the excitations. Automatic maneuver injection at higher frequencies and with higher amplitudes was designated as too dangerous to conduct on the helicopter in the hover frame while the rotors were rotating. Figure 21 shows an overall good agreement with the data. These models were used for stability and robustness analysis of the controllers. Therefore, safety factors have been applied to the actuator bandwidth in Ref. [28] when computing the stability margins to account for any possibles errors in the determination of the actuator models. The actuator dynamics estimated in this study are slower than actuators used in smaller UAVs [31].

5.2. Flight Dynamics of CoAX 600 in Hover Frame

Low-order equivalent system models of the rotorcraft rate response in the hover frame were estimated using the recorded test data. The translational motion states were omitted, since the high friction of the hover-frame wheels on the ground allowed only a highly nonlinear translational response, at very high cyclic and lateral inputs, which are unrealistic in the normal operation of a rotorcraft. The tfest function of the Matlab System Identification Toolbox was used to estimate the following transfer functions for the roll rate p, pitch rate q, and yaw rate r responses. Independent transfer functions were estimated for each axis, since no significant cross-axis coupling was noticed in the maneuvers. This is a major difference when compared with the free-flying rotorcraft with a piston engine, which shows a strong roll–yaw coupling due to its mass distribution. The helicopter in the hover frame was operated by an electric motor.

$$\begin{array}{c}\hfill G_{p{\theta }_c}={\displaystyle \frac{-0.07216s+0.005195}{s^2+0.06733s+8.989}}\end{array}$$

(9)

$$\begin{array}{c}\hfill G_{q{\theta }_s}={\displaystyle \frac{0.09293s+0.01107}{s^2+0.1682s+4.738}}\end{array}$$

(10)

$$\begin{array}{c}\hfill G_{r{\theta }_{\mathrm{yaw}}}={\displaystyle \frac{-0.176s+0.007484}{s^2+0.559s+0.6101}}\end{array}$$

(11)

The model fits can be seen in Figure 22 and the pole-zero map of the estimated transfer functions is visualized in Figure 23. The structure of the transfer functions was chosen based on the analysis of the physics of the system and the recorded data. The model structure determination process and achieving a good model fit were challenged by nonlinearities of the system due to stiction and friction. Furthermore, the helicopter was operated in a confined area, which could affect the airflow. The development of a high-fidelity simulation model similar to Ref. [28] was not pursued, since the hover-frame helicopter dynamics was only analyzed in hover, which eliminates the need for a global modeling approach. Furthermore, there was no need for the fine-tuning of the flight control laws of the gimbal-mounted helicopter. The model was also not used for training the pilots to operate the helicopter in the hover frame. It was mainly used to ensure the stability of the closed-loop helicopter in the hover frame, albeit with the gains tuned for free flight. The closed-loop flight tests in the hover frame allowed assessing the flight control functions, and their verification in principle, while the dynamic characteristics of the rotorcraft could not be assessed.

Figure 22 shows that the model fits are acceptable and capture the overall trend of the rotorcraft response, despite some remaining deviations of the model response from flight data. Nonlinear or higher-order dynamics, not captured in the low-order model structures, could be the main factors behind the remaining discrepancies. The pole-zero map of the estimated transfer functions reveals that the helicopter dynamics in the hover frame demonstrates significant differences when compared with the free-flying airframe poles, as reported in Ref. [28]. The addition of the zeros close to the origin is physically feasible due to the offset of the joint and the CG of the rotorcraft. The yaw response of the hover-frame helicopter is the closest to that of the free-flying rotorcraft, reported in Ref. [28]. The time domain response of the roll and pitch rate resemble that of a pendulum, since the center of gravity of the helicopter is below the helicopter mounting point. This is also confirmed by the stable but low-damped poles of the roll and pitch motion seen in Figure 23.

Many companies, especially in the fields of urban and advanced air mobility, are utilizing hover frames to test their flight control systems and functions prior to commencing free flights. The results in this study show that such hover frames, while valuable for the validation of the system, result in significant changes in the rotational dynamics of the flight vehicle and should, therefore, be used with caution for flight control law validation purposes.

6. Conclusions

A 600 kg coaxial rotorcraft was converted to a UAV. A robotic actuator system was developed and retrofitted into the cockpit to enable unmanned flight. The robotic actuator system is directly connected to the cockpit inceptors and does not require a modification of the rotorcraft’s mechanical control system. This minimally invasive approach makes the reversible conversion of a new CoAx 600 rotorcraft to a UAV possible with limited effort and in limited time. This is, to the best knowledge of the authors, the first time a robotic control system has been used for the unmanned flight of a full-size rotorcraft, and it demonstrates the feasibility of this approach.

The nonlinear kinematics of the robotic system are canceled by the onboard feed-forward robot control software, which was developed using a Simscape multi-body simulation model and numerically adjusted based on limited manual measurements on the helicopter. The applied numerical grid adjustment method was described. The following lessons were deduced from the development process:

• The operation of the pilot stick using two actuators working together to execute commands in the lateral or longitudinal directions was effective in both theory and practice.
• The multi-body simulation model, coupled with the actuator models, was an indispensable tool in designing the robotic actuator system. It was used for verifying the kinematics, the selection of the actuator components, and the system dynamic and power requirements.
• The Simscape multi-body model can be used to derive inverse-kinematics look-up tables for the onboard feed-forward robot control software to cancel the nonlinear (multi-dimensional) kinematics of the control rods. However, due to manufacturing tolerances, the simulation-based two-dimensional look-up tables needed to be corrected using measurements on the actual system. The methods of Section 2.2 were developed for this purpose.

An electronic flight control system, consisting of primary and emergency flight control paths, was designed and developed, allowing the pilots to control the aircraft using RC transmitters. The onboard system also sent the flight parameters to a ground station via a telemetry link to monitor the flight tests. It was demonstrated that the described flight control system satisfies the requirements of the UAV operation according to SAIL II in the context of SORA.

The flight control systems and functions were tested in a HIL setup and later in a hover frame, before commencing the free-flight test campaign. The data captured on the hover frame were used to estimate linear low-order system models of the actuator dynamics, as well as the rotational dynamics of the helicopter while flying in the hover frame. It was demonstrated that, although the hover frame is a valuable tool for testing the systems and crew training, it is not a suitable means for testing flight control functions due to differences of the rotorcraft flight dynamics between the hover frame and free flight, as demonstrated in Section 5.2. The differences are mainly the result of the offset of the mounting position of the rotorcraft on the hover frame from its center of gravity. These considerations are important due to the increased use of such hover frames in urban and advanced air mobility research and development. With regards to the system, avionics, and the HIL tests, the following conclusions were drawn:

• The overall resulting actuator dynamics from flight control law commands to the actual deflections at the swashplate were estimated in Section 5.1. Due to aerodynamic loads on the full-size rotorcraft, the actuator dynamics were slower than those of smaller UAVs. Such in-flight actuator tests were, therefore, essential to identify the correct actuator dynamics to be used in flight control law design.
• The HIL tests revealed that the remote pilots could not effectively operate the unmanned rotorcraft in open loop, due to the actuator dynamics and system time delays. This information was further motivation for designing closed-loop flight control laws and keeping them active at all times during the unmanned flight tests.

The flight tests took place in the attitude mode flight control law at the national test center for unmanned aircraft at the Magdeburg–Cochstedt airport (EDBC) in Germany. The remote operation of the rotorcraft was possible with limited pilot workload, despite windy days with significant gusts. The rotorcraft with the closed-loop flight controller showed excellent flying qualities. However, it was observed that only a limited section of the operating volume could be used for the flight tests, since the pilots could not safely identify the orientation of the rotorcraft at higher distances. Therefore, a velocity controller is required for more complex maneuvers.