Flight Simulation

RAPID INTEGRATION, DEVELOPMENT AND FLIGHT TEST OF HELICOPTER FLIGHT CONTROL LAWS

Jack Shue Stacey L. Winger [email protected] [email protected] Principal Engineer, Handling Qualities Principal Engineer, FBW & Control Laws IPT Lead

Bell Helicopter Textron Inc., Fort Worth, Texas

Arthur W. Gubbels Kris Ellis [email protected] [email protected]

Research Officer, Flight Mechanics and Avionics Research Officer, Flight Mechanics and Avionics Flight Research Laboratory

National Research Council of Canada Ottawa, Ontario

ABSTRACT

In 2009, Bell Helicopter developed and flight test advanced optimal/robust control laws. An innovative rapid prototyping process was employed utilizing real-time Matlab/Simulink® executing on a rugged laptop to develop and flight test the con-trol laws on a fly-by-wire test bed aircraft. Control law gain margin, phase margin, bandwidth calculation and compensator selection were designed using Bell’s three loop optimization technology Matlab/Simulink® M-file algorithm. A desktop simulator was used to merge the control laws with a non-linear COPTER math model S-function for simulation testing. A COPTER math model running in Bell’s Simulation Lab assisted in real-time Simulink® integration, logic testing and pilot’s flight control force feel system tuning. Both full and partial authority advanced control laws were evaluated in the National Research Council of Canada (NRC) Bell Model 412 Advanced Systems Research Aircraft. Technology demonstrations were conducted and selected handling qualities maneuvers were performed to evaluate the capabilities of the new control laws.

1

NOTATION

ACF Advanced Control Feedback ACLAWS Advanced Control Laws Alpha Angle of Attack ASRA Advanced Systems Research Aircraft Ax Longitudinal Acceleration Ay Lateral Acceleration Az Vertical Acceleration Bell 412 Bell Helicopter Model 412 Aircraft Beta Sideslip Angle CIFER® Comprehensive Identification from Fre-

quency Responses CONDUIT® Control Designers Unified Interface COPTER Comprehensive Program for Theoretical

Evaluation of Rotorcraft CP1-CP8 Control Potentiometers FBW Fly By Wire FCC Flight Control Computer gps alt, Hgps GPS Altitude GPS Global Positioning System Hind Indicated Altitude HMU Health Monitoring Unit Presented at the American Helicopter Society 66th Annual Forum, Phoenix, Arizona, May 11 – 13, 2010. Copyright © 2010 by the American Helicopter Society International, Inc. All rights reserved.

Hp Pressure Altitude ID Identification INS Inertial Navigation System laser alt Laser Altitude lat Latitude long Longitude mix alt Mixed Height Above Ground MTE Mission-Task-Elements NRC National Research Council of Canada OAT Outside Air Temperature p Roll Rate Roll Acceleration phi Roll Attitude psi Heading Angle q Pitch Rate q Pitch Acceleration r Yaw Rate r Yaw Acceleration radalt Radar Altimeter SCAS Stability & Control Augmentation System theta Pitch Attitude TRC Translational Rate Command UAV Unmanned Aerial Vehicle Vx X Axis Velocity Vy Y Axis Velocity Vz Z Axis Velocity Xe Longitudinal Position Ye Lateral Position

2

INTRODUCTION

In 2009, Bell conducted company-funded research on the next generation of advanced flight control laws at its XworX facilities in Arlington, Texas. The focus of this activity was to enhance safety through reduced pilot workload and auto-mated flight. The advanced control laws, or ACLAWS, were developed using advanced optimal/robust control the-ory. The ACLAWS offer exceptional capabilities in the areas of robustness, gust rejection, and control decoupling. In addition, the control laws are designed to automatically switch to the desired flight mode resulting in the elimination of cockpit control mode switches. In general, the philosophy is simple; the aircraft holds the current flight condition until the pilot commands a change. Features of the ACLAWS include automatic hover hold with single control input land-ings, speed hold, heading hold, and altitude hold. The con-trol laws have been developed for both conventional partial authority flight control systems and future full authority fly-by-wire (FBW) aircraft. The ACLAWS were initially evaluated with a desktop simu-lator, and in Bell’s Engineering Simulation Lab. They were then flight tested on the National Research Council of Can-ada (NRC) Model 412 Advanced Systems Research Aircraft (ASRA) airborne simulator (Fig. 1). This aircraft has the unique design of both conventional and fly-by-wire flight control systems. The safety pilot in the right seat flies the aircraft with the production aircraft flight controls. How-ever, in the left seat, the evaluation pilot can fly the aircraft through an experimental fly-by-wire flight control system. The evaluation pilot’s controls are not connected mechani-cally to the control surfaces. Instead, they are connected electrically to the flight control computer, which, based on the design of the flight control laws, sends commands to actuators that move the flight controls. In the event of evaluation pilot loss of aircraft control, the safety pilot can take control of the aircraft at any time. This is an ideal setup for the development and testing of new flight control laws, since the safety of the crew and aircraft are assured by the safety pilot. A unique component of the development and testing of the ACLAWS is the use of a laptop computer running the con-trol laws using Matlab/Simulink® in quasi real-time. With this method, code generation, compilation, linking, and de-ployment to the host computing system are not required. This allows the control law designer the ability to disengage the control law computer, make changes, then reengage the new control laws in a mater of minutes. This significantly reduces the cycle time for control law development. In addi-tion, the same laptop is used to run stand alone simulations, real-time engineering simulations, and airborne simulations

in the NRC 412 ASRA. Thus, the flight control designer can evaluate the control laws on the ground, then quickly move to flight test evaluation. The process that made this rapid ACLAWS prototype devel-opment possible contains five steps, as shown in Fig. 2. The following sections will detail the history of this program and discuss in detail these five steps in the development.

INITIAL CONTROL LAW DESIGN

The first step in the ACLAWS development process was to design the desired control laws in the Matlab/Simulink® environment. Then, the control laws were optimized for a Bell Model 412 since the NRC 412 ASRA was used for evaluating the control laws in flight. Once the control laws are proven through test, they can be optimized for different helicopters. The following sections detail this process.

Fig. 1. NRC 412 ASRA.

3

Mathworks Simulink® Design Tool

Bell’s ACLAWS are modeled entirely with Mathworks Simulink® (Refs. 1–2) and associated toolboxes. Math-works Simulink®, a Matlab toolbox, is one of the most pow-erful software packages for control and modeling. It can provide multi-domain simulation and model-based design for dynamic and embedded systems. It also contains an in-teractive graphical environment and a customizable set of block libraries that permit engineers to design, simulate, implement, and test a variety of simulated nonlinear sys-tems, such as flight controls, guidance, navigation, commu-nication, signal processing, and data recording. Mathworks Simulink® has been widely adapted by the aero-space industries. Its S-functions can be written to support arbitrary input/output dimensions compatible with legacy programs. An S-function is a Matlab tool to transform C and FORTRAN codes into a Simulink® block so that the non-Matlab programs can be used in the Matlab Simulink® envi-ronment. In the ACLAWS design methodologies, this func-tionality is used in control law optimization, integration with aircraft math models and communication interfaces between computer systems or devices.

Linear Math Model

To simulate a linear math model of aircraft dynamics, the parameter identification of the aircraft must first be estab-lished. The CIFER® (Comprehensive Identification from Frequency Responses) program (Ref. 3) was used to estab-lish the associated linear models from flight test data. These techniques were similar to those used on an earlier Bell con-trol law development effort (Ref. 4). Five sets of flight test data that were collected from the NRC 412 ASRA were used in the CIFER® analysis. The data were collected at hover, and at 30-, 60-, 90-, and 115-kn airspeed. As indicated in the Fig. 3 procedure, linear models were generated using each of the five flight test data sets. These sets were then converted into a full set of linear Matlab/Simulink® models and used in the initial tuning of the ACLAWS. Three Loop Control Laws Design

In the control law architecture design, Bell’s three-loop con-trol laws were employed (Fig. 4). Several Matlab optimiza-tion files were established to quickly determine the control error gains, compensators, and lead-lag transfer functions for the control laws. Advanced Control Feedback (ACF) in the

Initial Control Law

Design

CLAWS COPTER S-Function

Desktop Simulator

Real-Time Simulator

Ethernet S-function

ACLAWS Integration with the NRC ASRA

Nonlinear Simulation

Flight test I/O check Communications

check Pilot Control Feel Control Sensitivity

Gain Tuning New Compenstaors Rapid ACLAWS New maneuvers

Integration

ACLAWS Flight Testing

Fig. 2. Control laws rapid prototyping methodology.

secdeg/25

secdeg/60 2

q

q

secdeg/60

secdeg/80 2

p

p

secdeg/20

secdeg/80 2

r

r

Verify control sensitivity for each axis

Add rate and / or saturation limits if needed

Emergency Mode

Each 30 knots for a linear model.

Insure cross robustness check

Verify frequency and damping ratio

Each 30 knots for a linear model.

Insure cross robustness check

Verify frequency and damping ratio

Arrange all limiter. Tune gains Verify all gain

margins, phase margins and bandwidths

Flight Mechanics for maximum acceleration

per inch of control input

Linear Models for the first loop robustness

development

SCAS mode design with lead/lag and integrator

gain logic

Build full linear model Gain schedule systems for

entire envelope

Fly-By-Wire ACLAWS Design

Build Nonlinear COPTER S-Function for flight test

Simulation Lab Integration and flight test

Fig. 3. Control law development flow chart.

4

first (inner most) loop is employed for stabilizing the sys-tem. Unlike the standard robust control laws design, the decoupling of each individual axis is emphasized on this ACF. Note that system delays in actuators and sensor meas-urement are also considered in the ACLAWS design. During development, switches were needed to evaluate the different ACLAWS loops and modes. This switching was done with software manual switches as shown in Fig. 5. The switches were used to Turn on individual loops for testing through the individ-

ual axes. Verify the individual control sensitivity per the pilot re-

quirement. Switch to alternate loops without restarting Simulink®. Activate automatic functions. Turn on all ACLAWS modes and features with a single

switch. Configure the control laws for either the engineering

simulator or the NRC 412 ASRA. CONDUIT® Design

CONDUIT® (Ref. 5) design was employed to verify the ACLAWS augmentation and integration. The CONDUIT® automatic gain search was used to determine the best error solutions; however, it turned out to be very limited in com-pensator and lead-lag transfer function selection. Therefore, CONDUIT® was used for verification purposes only. An example of the CONDUIT® design is shown in Fig. 6. In this figure, it is shown that four more blocks are generated for assisting with the robustness of ACLAWS.

The last three blocks are control sensitivity blocks in the longitudinal, lateral, and directional axes. For detail of con-trol sensitivity functions, Ref. 6 can be used as a guideline. The control sensitivity function is used to determine the pilot control feel in maneuver mode. The fourth block, the coefficient of uncertainty block, was generated based on Bode plots of disturbance attenuation from control to disturbance. The coefficient of uncertainty block is designed using a disturbance rejection bandwidth concept, which introduced a 3 dB trade-off region. The un-certainty criterion is to satisfy a similar ADS-33 disturbance rejection requirement. Instead of using 0.9 as the distur-bance rejection average bandwidth criteria, the total band-width is calculated. An M-file S-function was designed to check the –3 dB crossover-frequency to determine the per-centage of uncertainties, which the control laws can auto-matically damp out. All standard blocks of the CONDUIT® design were tested for verification purposes. It was shown that the gain margin, and phase margin are very close to Bell’s M-file algorithm design. However, the CONDUIT® bandwidth calculation is much higher than that of the real aircraft response, while Bell’s M-file calculation was very close to aircraft perform-ance. In all cases, the ACLAWS design satisfied the CONDUIT® design requirements. It was also found that CONDUIT® and Bell’s M-file algorithm design had the potential to tune the individual axis gain margin, phase margin, and band-width with the least interference between the axes. It is also possible to tune the gain margins of the vertical and pedal axes to infinity.

Steady State Aerodynamics Info

Outer Loop

Robust Feedback

Inner Loop I

Feedback States

Actuator Command

Stick Control Inputs

SCAS Outputs Aircraft

Plant Guidance

Loop

Loop II

Autopilot

Loop III

ACLAWS

Fig. 4. Simplified ACLAWS design.

5

Fig. 5. ACLAWS software manual switch design.

6

DESKTOP SIMULATOR

After the initial control law design was developed in the Matlab/Simulink® environment and tuned with CONDUIT®, the control laws were ready for testing with a full non-linear math model in the desktop simulation envi-ronment. The standard Bell non-linear math model is COPTER (Comprehensive Program for the Theoretical Evaluation of Rotorcraft) (Ref. 7). COPTER simulates the main and tail rotor characteristics with a blade element model. Each rotor blade is divided into individual segments that can be associated with unique airfoil properties. In time domain calculations, every segment of every blade is evalu-ated for airspeed and angle of attack. The lift, drag, and pitching moments are summed to yield instantaneous rotor forces and moments. The COPTER program was packaged as a Matlab S-function, so that the ACLAWS could be readily developed and evaluated on engineering workstations. The COPTER program is coupled with the appropriate airframe and rotor definition files to produce a non-linear simulation of a Bell

412 aircraft. The combination of COPTER and an S-function at Bell is called the COPTER S-function (Ref. 8). An additional S-function is also used that provides an inter-face for a joystick so that the engineer can “fly” the simula-tion to evaluate the ACLAWS. Thus, the desktop flight simulator is comprised of the following components:

1. COPTER S-function 2. Joystick S-function 3. Flight display M-file S-function 4. Real-Time Block S-function 5. Flight Control Laws (ACLAWS) 6.

The simplified desktop simulator is shown in Fig. 7. Using the COPTER S-function assists the control law de-signer in finding better compensators and gains from real-time nonlinear math model simulations. The desktop simu-lator integration helps the engineer design the ACLAWS quickly and effectively by allowing the engineer to “fly” the nonlinear math model on a desktop computer. This allows the engineers to check the control sensitivity function per

Control Sensitivity BlocksPedal

Long Lat

Coefficient of Uncertainty Block

Control Sensitivity BlocksPedal

Long Lat

Coefficient of Uncertainty Block

Fig. 6. CONDUIT® design example.

7

pilot command. It is also valuable while troubleshooting the logic design.

REAL-TIME SIMULATOR

The next step in the ACLAWS development process was to integrate an ethernet interface into the Simulink® model. This interface enables data exchange between the control laws and the real-time simulator in the Bell Simulation Lab. In previous control law development efforts, C-code was auto-generated from the Simulink® model using the real-time workshop. This code was then compiled with bridge code that interfaced the model with the real-time simulation. By adding the Ethernet interface to the Simulink® model, the need to do this was eliminated. This reduced the cycle time for control law modifications to a few minutes, which is approximately a 90% reduction. In addition, a laptop com-puter was used to run the control law package. The laptop model included Ethernet S-function blocks for FCC and INS communi-

cation. Matlab®, Simulink®, Control Tool Box. ACLAWS. All manual switches which are not implemented in the

aircraft. Bell Helicopter’s advanced real-time flight simulation capa-bility spans more than five decades. This simulation capa-bility has been used in engineering development of numer-ous helicopter and tilt-rotor aircraft. Most recently, Bell’s Avionics and Simulation Development Center (ASDC) has been exploited for fly-by-wire flight control law develop-ment, pilot evaluation and training, flight training system development, aircraft hardware in-the-loop testing, advanced concept development, marketing support, and customer demonstrations. The ACLAWS simulator was developed quickly and inex-pensively, using existing cockpit hardware and the ASDC

facility. In addition, existing math models and other simula-tion components were reused or modified to build a com-plete real-time simulator. As the program has progressed, the real-time simulator capabilities have been enhanced as necessary. Initial integration of the real-time ACLAWS in the Bell simulation lab was to insure that the communication S-functions integration with ACLAWS was able to be run be-fore proceeding to flight test. It also provided an avenue to develop the desired flight control force characteristics for the unique trim flight controls. It was also very useful for test-ing the control law logic switching and checking for events that would cause the fly-by-wire test bed evaluation system to disengage. In addition, the sensor noise data was ex-tracted from flight test data and inserted into Bell’s simula-tion lab sensor package to produce simulated sensor data quality that is similar to the aircraft sensor data. This addi-tional noise package in the simulation sensor feedback sys-tem has added to the fidelity of the simulation and made the simulation testing closer to the real flight test. Flight Control Computer

A key component of the ACLAWS rapid development proc-ess was the use of the Matlab Simulink® tool running as a real-time process. This was one of the major innovations developed in the program. The ACLAWS run in a slave mode with the simulation executive (in the case of the Bell simulation lab) providing the synchronization pulse via an ethernet packet. The host computer system for Bell’s ACLAWS is a Pana-sonic Toughbook CF-52. This computer executes the con-trol laws utilizing Matlab Simulink® in real-time while fly-ing the simulator or test bed aircraft. The only connection to the simulation host is a single ethernet cable. Several S-functions in the Simulink® environment are used to com-plete the real-time communication. The data received from the simulation host are standard helicopter sensor signals

COPTER

S-Function ACLAWSPilot Command

(Joystick S-Function)

Sensors

Feedback

Actuators

Nonlinear Math Model

Flight Display S-Function

Fig. 7. Simplified desktop simulator diagram.

8

and pilot switch inputs. The data transmitted from Bell’s ACLAWS laptop are the commanded position for the four pilot controls. This simulates the commands that would be sent to the fly-by-wire actuators on a full authority flight control system. NRC, developed ethernet S-functions, similar to those de-scribed in Ref. 9, were integrated into the Matlab/Simulink® model to exchange data with the real-time math model in the Bell Simulation Lab. This process eliminated the need for Simulink® c-code with the bridge c-code to run real-time simulations. Verification of the ethernet functions in the

Simulation Lab eliminated the requirement to troubleshoot this function in-flight. This method allowed easy modifica-tion to the control gains and compensator design. There are three ethernet S-functions used in the rapid ACLAWS de-velopment. Note that these same functions are used both in the real-time simulator and in the test bed aircraft. FCC Data Packet Receive: The real-time math model transmits a packet containing all required non-inertial data including cockpit control positions, switches, engine data, air data, radar altitude and control law tuning settings (Fig. 8). The math model serves as the master clock for the simu-

Betabeta (deg)

TorqueTorque (%)

TASTAS (kts)

Status_MessageStatus Message

SP_Ped_PosnSP_Ped_Posn

SP_Lon_CycSP_Lon_Cyc

SP_Lat_CycSP_Lat_Cyc

SP_Col_PosnSP_Col_Posn

sfun_fcc_rcv_tr

Receive FCC PacketS-Function1

RadaltRadalt (ft)

Pedal_PosPedal Position (in)

Ped_DetentPed_Detent

OATOAT (C)

NR_RPMNR_RPM

Longitudinal_CyclicLongitudinal Cyclic Position (in)

Lon_DetentLon_Detent

Lateral_CyclicLateral Cyclic Position (in)

Lat_DetentLat_Detent

I_YAW_FRC_INI_YAW_FRC_IN

I_ROLL_FRC_INI_ROLL_FRC_IN

I_PITCH_FRC_INI_PITCH_FRC_IN

I_COLL_FRC_INI_COLL_FRC_IN

GPS_TimeGPS Time

Function_SwitchesFunction Switches

Event_NumberEvent Number

Eng_Temp2Eng_Temp2 (C)

Eng_Temp1Eng_Temp1 (C)

Demux

Collective_SwitchesCollective Switches

Collective_SliderCollective Slider (volts)

Collective_PosCollective Position (in)

Col_DetentCol_Detent

CP8CP8 (0-10)

CP7CP7 (0-10)

CP6CP6 (0-10)

CP5CP5 (0-10)

CP4CP4 (0-10)

CP3CP3 (0-10)

CP2CP2 (0-10)

CP1CP1 (0-10)

Baro_AltBarometric Altitude (ft)

AlphaAlpha (deg)

Fig. 8. FCC data packet receive S-function.

9

lator with the packet being transmitted at regular 16 msec cycles. The Bell ACLAWS run in a slave mode waiting for this packet to execute each frame. INS Packet Receive: The real-time math model also transmits sensor data to simulate the data packet from the NRC INS and GPS. The data include aircraft attitudes, an-gular rates, linear accelerations, global position, and laser altitude (Fig. 9). Final Commands Transmit to FCC: The signals sent back to the simulation math model are the commanded posi-tion for the four FBW actuators, a synchronization counter and four beep trim commands (Fig. 10).

ACLAWS INTEGRATION WITH THE NRC ASRA

After the ACLAWS were verified in the Bell Simulation Lab, the next step was to integrate the real-time Mat-lab/Simulink® control law model with the NRC Bell 412 helicopter utilizing the same laptop computer that was used in the simulator. NRC 412 Advanced Systems Research Aircraft (ASRA)

The Flight Research Laboratory of the Institute for Aero-space Research, NRC has been active in the development, design, and manufacturing of “Fly-By-Wire” or variable stability helicopters since the conversion of a Bell 47 to this type of configuration in 1961.

The design for ASRA requires that the FBW system be “sin-gle string” in nature. This is a requirement in order to retain a high level of flexibility, while keeping costs low. This “single string” nature allows: A single set of FBW actuators; One, non-redundant flight control computer (FCC); A single set of aircraft state sensors; and A single set of flight control software.

These features significantly reduce the maintenance and operating costs associated with the aircraft. This simplicity of design facilitates the incorporation of software changes without the overhead of multiple coding sources, multiple languages or operating systems, and in-depth code valida-tion; all of which are necessary for production systems, but would be overly prohibitive for flexible, time critical re-search programs. Inherent in the single string architecture is a reliance on the aircraft safety systems to protect the crew. The heart of the safety system is the Health Monitoring Unit (HMU) which, among other functions, uses a flight path prediction scheme to prevent unsafe conditions from occur-ring. As a final line of defense, a safety pilot is required to mitigate the effects of a system failure and prevent excur-sions outside of the safe flight envelope. This operating methodology places high demands on the safety pilot, but affords the advantages of increased flexibility by retaining the entire certified operational envelope of the aircraft. It allows the aircraft to be maneuvered aggressively in close proximity to the ground, and to perform unrestricted takeoffs and landings with the FBW system engaged.

rr (deg/sec)

qq (deg/sec)

pp (deg/sec)

VzVertical Velocity (ft/s + up)

TimeTime

ThetaTheta (deg)

Status_WordStatus Word

sfun_honeywell_thd

Receive INS PacketS-Function

Raw_Las_RngRaw Laser Range (ft)

PsiPsi True (+/- 180 deg)

PhiPhi (deg)

Vx_ftNorth Velocity (ft/s)

MixAltMixed Height above Ground (ft)

Best estimate of AGL

LongitudeLongitude (deg)

LatitudeLatitude (deg)

LasAltLaser Altitude (ft)

GPS_AltGPS Altitude (ft)

Vy_ftEast Velocity (ft/s)

DemuxAz

Az (ft/s/s)

AyAy (ft/s/s)

AxAx (ft/s/s)

Fig. 9. INS/GPS packet receive S-function.

10

The ASRA control system structure used for this project, as shown in Fig. 11, consists of both the safety pilot and evaluation pilot controls. In the ASRA, the safety pilot flies the helicopter using the standard mechanical control system, and is responsible for assuming control in the event that a computer drops off-line, or a potentially dangerous situation arises. The evaluation pilot's controls, when engaged by the safety pilot, control the ASRA through a fully programma-ble, full authority fly-by-wire control system. To provide this capability, four high-quality and flight-critical hydraulic actuators, designed by HR Textron, are attached to the me-chanical control runs in parallel. This architecture offers the advantages of having the safety pilot's controls move in re-sponse to the FBW actuators, allowing the safety pilot to monitor the control system's input shape and amplitude, the helicopter's control margins, and to some extent, the evalua-tion pilot's workload. Consequently, by having the mechani-cal controls back-driven, the safety pilot is able to sense the control activity demand by any given control system. Inte-gration of this system is simplified by the fact that the Bell

412 can be flown with the Stability and Control Augmenta-tion System (SCAS) off, and that the SCAS off dynamics are suitable as the FBW reversion since the aircraft can be safely recovered from unusual attitudes without the help of the SCAS. Thus, accounting for the effect of the SCAS on the control system is not required. NRC 412 aircraft is configured with five crew stations as follows. In the front cockpit are stations for a safety pilot on the right and an evaluation pilot on the left. In the cabin are stations for the NRC FCC operator engineer, and two Bell engineers for control law evaluation and laptop computer operation. The NRC FCC provides eight tunable knobs to be utilized for control law gain tuning. These knobs can be adjusted without shutting down the Simulink® control laws. However, the function and range of the knobs must be pre-determined before the flight test. When the range or granu-larity in these knobs is exhausted and additional tuning is required, the control laws can be modified in flight. First, the safety pilot takes control of the aircraft and the control

Sync_Counter

Sync Counter

sfun_send412_final_drives_tr

Send Final commands to the FCC

[Ped_Trim]

Ped_Trim

[Lon_Trim]

Lon_Trim

[Lat_Trim]

Lat_Trim

Coll_Trim

Coll_Trim

Coll_FTR_ON

Coll_FTR_ON

AC_IN_DPED_CMD

A/C Input Pedal Position (%)

AC_IN_DLAT_CMD

A/C Input Lateral Stick Position (%)

AC_IN_DLON_CMD

A/C Input F/A Stick Position (%)

AC_IN_DCOL_CMD

A/C Input Collective Position (%)

Ped

Lat

Lon

Ped

Col

Col

Lat

F/A

Col

Fig. 10. Final commands transmit to FCC S-function.

11

laws are disengaged. Then, the Bell engineer can change gain values, compensator design, lead-lag transfer function, or even generate other loops to stabilize the system. These capabilities, plus the other design techniques discussed, en-able rapid design and make the control laws design process quick, accurate, and effective. Flight Control Computer Integration with the NRC 412 ASRA

When integrated with the NRC 412 ASRA, the ACLAWS run in a slave mode with the NRC FCC rather than the simu-lator host computer providing the synchronization pulse via an ethernet packet. The integration of the ACLAWS laptop with the NRC 412 ASRA FCC is illustrated in Fig. 11. As in the Bell Simulation Lab, several S-functions in the Simu-link® environment are used to complete the real-time com-munication. The data received from the NRC FCC are stan-dard helicopter sensor signals. The data sent to the NRC 412 FCC from Bell’s ACLAWS laptop are the delta com-manded positions for the four fly-by-wire actuators relative to the engagement position. This capability to utilize a real-time Simulink® model had been previously prototyped by NRC on the ASRA in a simple single-axis controller, but had never been employed in a full 4-axis control law. With verification of the laptop ethernet interface in the Simulation Lab, troubleshooting this function in flight test was avoided. However, there are a few components needed in the simulation model that are not needed when testing in the aircraft. This includes sensor and actuator models to emulate the hardware in the aircraft. These components are easily disabled for flight testing with a single switch in the ACLAWS. In addition, so that the different modes could be isolated during initial flight testing, software manual switches were designed into the ACLAWS to allow rapid

in-flight switching of the modes to the desired combination. Since these switches won’t be required once the design is finalized, they are not integrated into the pilot’s controls. Using the same methodologies from the desktop simulator to the Bell Simulation Lab to flight testing, made the entire integration easy, quick, and accurate. The NRC FCC records all aircraft data and fly-by-wire ac-tuator positions. However, built into the ACLAWS is the ability to record not only this data, but any parameter inter-nal to the control laws. This data is recorded continuously while the ACLAWS are running for both prime and non-prime data with the record and event numbers automatically encoded in the data stream. Prime data is tagged using a data on/off button on the pilot flight controls. The data file is automatically saved with the flight and date encoded in the file name for accurate documentation of the flight data. After each flight, the data is processed with a Matlab script that automatically parses each data record into a separate file and generates time history plot files. The data is then placed on a shared drive for analysis by the engineers and archived.

ACLAWS FLIGHT TESTING

The last step of the ACLAWS development process was flight test on the NRC 412 ASRA helicopter. The NRC 412 controls are arranged such that the pilot’s position functions as the safety pilot with the capability to manually regain control of the aircraft, and the copilot’s position functions as the evaluation pilot for the ACLAWS with FBW control, as detailed in Ref. 10. In this configuration, the development engineers can fly in the passenger compartment and make in-flight ACLAWS modifications, and assist in evaluating changes during the flight evaluation. The ACLAWS version tested in Bell’s Simulation Lab is the same as is tested in the NRC 412 aircraft. Once initial ground integration in NRC 412 aircraft was finished, the tasks of ACLAWS develop-ment in NRC 412 becomes a matter of gain tuning. Flight Test Development and Technology Demonstra-tions

Through the use of the development tools and techniques discussed in this paper, Bell’s ACLAWS were advanced much more quickly than in a typical development program. The program was begun in the forth quarter of 2008 with only the core three-loop control law design in place from previous work. By March 2009, the control laws had been mated with both a desktop simulation and a newly developed Bell 412 real-time simulator, and progressed through initial tuning for the 412 aircraft. The first development flight test on the NRC 412 aircraft occurred in April, 2009. After two weeks of sensor integration and control law developmental testing, low-speed SCAS and attitude modes were

Project Actuator & Override Spring

Engage Circuit

FCC Sensors

HMU Control Feel Sys

Bell’s Laptop Simulink ACLAWS

Swashplate

SCAS Actuators

Mechanical Link

Evaluation Pilot (Left seat)

Safety Pilot (Right seat)

Ethernet

FBW Link

INS

Ethernet

Fig. 11. ACLAWS laptop and ASRA control system architecture.

12

operational. Next, in a one week flight test opportunity in May, the hover hold mode and low-speed operations were implemented, and high-speed SCAS and attitude modes flight testing was begun. In June, the NRC 412 ASRA was brought to Bell’s XworX facilities for two weeks of continued development and technology demonstrations. Several logic changes were added to make the ACLAWS mode switching seamless and switchless, and additional automated modes were added. At this point, only nine control law development flights had been conducted, but the low-speed ACLAWS were mature enough for technology demonstrations to both pilot and non-pilot evaluators. Technology demonstrations of the ACLAWS were performed for test pilots and Bell management, to evaluate the capabilities that are available with the ACLAWS. After the June flight test, the focus of the project was shifted to development and evaluation of the ACLAWS capabilities in a traditional partial authority flight control system. For the evaluation, SCAS actuator authorities and trim actuator rates were set to the same values as Bell’s recently certified Model 429 aircraft. Similarly to the full authority ACLAWS, the partial authority system adapted the three-loop control law structure. After approximately two weeks of development, integration and testing in Bell’s Simulation Lab was begun. After one week of flight testing that included four flight tests and approximate 6 flight test hours on the NRC 412 ASRA, the partial authority ACLAWS demonstrated: Automatic hover Low-speed operations High-speed flight SCAS and attitude modes

The second flight test of the partial authority ACLAWS oc-curred at Bell’s XworX facilities. After one week of addi-tional developmental flight testing on both control law ver-sions, back-to-back evaluations were conducted on the full and partial authority control laws. In addition, commercial and military customers evaluated the ACLAWS in the NRC 412 ASRA, and provided valuable feedback for future de-velopment activities. The aircraft was flown by over 30 Bell employees and mili-tary and commercial customers as evaluation pilots. Most of the evaluations pilots had no prior flight training. In every case, the evaluation pilot, with minimal instruction on how to operate the controls, was able to fly and land the aircraft in what were typically 20–25 kn gusting wind conditions. The summary of flight test hours is shown in Fig. 12. Approximately 5 hours of flight test time were flown by commercial and military pilots. The customer comments were all very positive, such as, “Significant reduction in workload and increase in precision, especially in degraded visuals,” “Very important, especially for night operations.” ADS-33 MTE Evaluation

The ACLAWS design is applicable to both commercial and military aircraft, but is currently tuned for a non-military aircraft. Nonetheless, selected ADS-33 Mission-Task-Elements (MTE) (Ref. 11) flight test maneuvers were em-ployed to demonstrate the capabilities of the ACLAWS de-sign. This testing was performed at Bell’s XworX facilities in October 2009. Note that this is not a complete ADS-33 evaluation/report. The maneuvers were flown as a spot

0 10 20 30 40 50 60 70

Total Flight Test Hours

ACLAWS Integration

Bell Demonstration

Military Pilot Demonstrations

Commercial Pilot Demonstration

ACLAWS Flight Test Development

Flight Test Activity

Time (Hours)

Fig. 12. Flight test hours summary.

13

check of the ACLAWS capabilities after approximately 15 hours of developmental flight testing on the full authority ACLAWS. In addition, the maneuvers were flown under high gusty wind conditions with no prior practice runs by the pilot. The results are shown here as an illustration of the capability of the ACLAWS to be quickly developed and tuned to the level of the ADS-33 requirements. The flight test data shown here were collected from evaluations utiliz-ing the full authority version of the ACLAWS. A unique trim center stick cyclic, unique trim small displacement ped-als, and traditional displacement collective controllers were used for the evaluation pilot controls. Since the Bell 412 aircraft is a utility aircraft, the cargo/utility category is refer-enced for all ADS-33 requirements. Maneuvers were flown in both good visual environments (GVE) and simulated de-graded visual environments (DVE) using “foggles.” The handling qualities were all rated as level 1 by the test pilot. Selected flight test results for the vertical maneuver, hover-ing turn and pirouette MTEs are detailed below. ADS-33 Vertical Maneuver MTE. For a utility aircraft, the purpose of the ADS-33 MTE vertical maneuver (ADS-33 Section 3.11.6), is to assess the heave axis controllability with precision station keeping. The maneuver is to be flown in low to moderate wind conditions. The maneuver is per-formed as follows: Establish a 15 ft hover Initiate a 25 ft vertical ascent and stabilize Descend to the original hover position and stabilize

Flight test results for the vertical maneuver MTE are shown in Figs. 13 – 15. The maneuver was flown with collective input only while the cyclic and pedals remained in the detent position throughout the test. This satisfies the requirement of no undesirable coupling with the pitch, roll, and yaw axes. Figure 13 shows the x and y position hold plot during the maneuver. It can be seen that the aircraft holds the position within 5-ft longitudinally, and 2-ft laterally throughout the maneuver. The ADS-33 requires ±3 ft for desired and ±6 ft

0 5 10 15 20 25 30-2

-1

0

1

2

3

4

5

Time (s)

Col

lect

ive

Inpu

t (in

ch)

Safety Pilot

Pilot

Trim Act. Pos. [Col_Detent_SW]

Fig. 14. Vertical MTE – collective input.

Time (Sec)

____Ye (ft)

- - - -Xe (ft)

(X, Y) Position - feet

Fig. 13. Vertical MTE – position response.

14

for adequate handling qualities in low to moderate winds. However, this maneuver was flown with 25 kn gusty winds. Figure 14 shows both the collective input from the test pilot and the safety pilot. The safety pilot collective is the control input that would be required by the pilot to fly the aircraft without the ACLAWS. Figure 15 shows the altitude re-sponse from both the GPS and pressure altitude. It is shown that the altitude response is smooth and steady, and satisfies the requirements for the vertical ascent and descent. ADS-33 Hovering Turn MTE. The purpose of the ADS-33 MTE hovering turn maneuver (ADS-33 Section 3.11.4), is to check the ability to perform a moderate rate turn in a hover while maintaining reasonable precision. The maneuver is to be flown in low to moderate wind conditions. The maneuver is performed as follows: Stabilize the aircraft at a hover at less than 20 ft altitude Complete a 180 deg turn in under 15 seconds

In the test of the ACLAWS, the hovering turn was per-formed using only a single pedal input by the pilot with no pilot input on the cyclic or collective. The maneuver was

completed in less than 10 seconds. Selected flight test re-sults are shown in Figs. 16–20. In Fig. 16, it is shown that the pedal input is higher than 1 inch in the entire maneuver. Since the winds were very gusty, the safety pilot pedal input is very active while the ACLAWS feedback adjusts for the changes in wind directions. The response of pitch, roll, and yaw rate are shown in Fig. 17. Note that during the turn, the yaw rate reaches 25 deg per second. Figure 18 shows the heading capture as well as pitch and roll attitudes. Figure 19 shows that the position drifts less than 5 ft during the turn, and then corrects back to the starting location once the turn is complete. Note that this is under high gusty winds with no pilot corrective action by the cyclic. The altitude re-sponse is shown in Fig. 20. Note that the GPS altitude is held within 3 ft satisfying the requirement for desired per-formance. ADS-33 Pirouette MTE. The purpose of the ADS-33 pir-ouette MTE (ADS-33 Section 3.11.5), is to check the ability to accomplish precision control of the aircraft simultane-ously in the pitch, roll, yaw, and heave axes. The maneuver is to be flown in low to moderate wind conditions. The ma-neuver is performed as follows:

0 5 10 15 20 25 30-20

0

20

40H

p (ft

)Pressure Altitude

0 5 10 15 20 25 30610

620

630

640

Hgp

s

GPS Altitude

Time (s)

Fig. 15. Vertical MTE - altitude response.

15

0 5 10 15 20 25 30-3.5

-3

-2.5

-2

-1.5

-1

-0.5

0

0.5

1

Time (s)

Ped

al I

nput

(in

ch)

Safety Pilot

Pilot

SCAS

Trim Act. Pos. [Ped_Detent_SW]

Fig. 16. Hovering turn MTE - pedal input.

0 5 10 15 20 25 30-10

0

10Filtered Pitch Rate

q_f

(deg

/s)

0 5 10 15 20 25 30-10

0

10Filtered Roll Rate

p_f

(deg

/s)

0 5 10 15 20 25 30-50

0

50Filtered Yaw Rate

r_f

(deg

/s)

Time (s)

Fig. 17. Hovering turn MTE – body rate response.

16

0 5 10 15 20 25 30-6

-4

-2

0

2

4

6

8

Eul

er A

ngle

(de

g)

0 5 10 15 20 25 30-100

-50

0

50

Time (s)

Hea

ding

(de

g)

Fig. 18. Hovering turn MTE – attitude response.

Time (Sec)

____Ye (ft)

- - - -Xe (ft)

(X, Y) Position - feet

Fig. 19. Hovering turn MTE – position response.

17

Stabilize the aircraft in a 10-ft hover over a point on the circumference of a 100-ft radius circle with the nose of the aircraft pointed at the center of the circle.

Laterally translate the aircraft around the circle keeping

the nose pointed at the center of the circle and following the circumference of the circle.

Maintain a groundspeed of 6–8 kn throughout the lateral

translation. Complete the maneuver in a stabilized hover at the start-

ing point. Flight test results of ADS-33 pirouette MTE test is shown Figs. 21 – 24. The tests were flown with the pilot wearing “foggles” to simulate degraded visual conditions. With the Bell CLAWS engaged, this maneuver requires the pilot to use lateral cyclic and pedal controls, and make only minor corrections with the longitudinal cyclic. The collective re-mains in the detent position throughout the maneuver. Fig-ure 21 shows the inertia longitudinal and lateral ground speeds. It is shown that the average groundspeed is higher than the required rate at approximately 10 kn, resulting in a total maneuver time of approximately 52 seconds. Figure 22

shows that the GPS altitude variation is within 4 ft during the pirouette maneuver. Figure 23 shows the pitch, roll, and yaw attitude response. The pirouette maneuver circle data is plotted in Fig. 24. Note that the test pilot flew this maneuver without any practice runs. The results indicate that the ma-neuver flown in degraded visual conditions is within ADS-33 requirements. The test pilot rated the ACLAWS under this environment with gusty wind as HQR 2 to 3.

CONCLUSIONS

Rapid integration, development, and flight test of advanced flight control laws were accomplished using a variety of control law development tools, simulations, and the NRC 412 ASRA. Both full and partial authority control law ver-sions were developed using the three-loop control laws as the core. The techniques used allowed a small team of engi-neers and pilots to quickly develop, flight test, evaluate, and demonstrate new control laws with very few hours of flight test time. The handling qualities were evaluated by flying selected ADS-33 MTEs with favorable results. Develop-ment of the ACLAWS continues in 2010 with the introduc-tion of new advanced automated features that are possible once the core control laws are in place.

0 5 10 15 20 25 304

6

8

10

Hp (

ft)

Pressure Altitude

0 5 10 15 20 25 30612

614

616

618

Hgp

s

GPS Altitude

Time (s)

Fig. 20. Hovering Turn MTE – altitude response.

18

0 10 20 30 40 50 60 70-3

-2

-1

0

1

Vx_

eart

h (k

not)

Inertial Speed - Forward

0 10 20 30 40 50 60 70-10

-5

0

5

Vy_

eart

h (k

not)

Inertial Speed - Sideward

Fig. 21. Pirouette MTE – ground speed response.

0 10 20 30 40 50 60 700

5

10

15

Hp (

ft)

Pressure Altitude

0 10 20 30 40 50 60 70618

620

622

624

Hgp

s

GPS Altitude

Time (s)

Fig. 22. Pirouette MTE – altitude response.

19

ACKNOWLEDGMENTS

The control law development and demonstration effort detailed in this paper was accomplished by a small team of engineers, pilots, and support staff from both Bell Helicopter and NRC. The success of this program is due to the insight, dedication, and long hours of the development team. At every step of the way, the team’s primary focus was saving lives through increased rotorcraft safety. While the level of demonstrated control law capability is impressive, when the short timeline and staffing on the program is considered, this was truly an outstanding effort by those involved. In addition, the collaborative effort between Bell and NRC was absolutely essential to achieve this level of accomplishment. The team members and a short description of their contributions follow. At Bell Helicopter in Fort Worth, Texas: Jack Shue, Principal Engineer, Handling Qualities (control law development technical lead); Stacey Winger, Principal Engineer, Fly-by-Wire and Control Laws IPT Lead (project lead); Eric Bird, Principal Engineer, Simulation (real-time simulation, ASRA Ethernet communications and flight test support); Kevin Christensen, Principal Engineer, Handling Qualities (control law development and flight testing); Troy Caudill, Principal Test Pilot (test pilot for the control law development); Nilesh Sahani, Sr. Engineering Specialist, Handling Qualities (partial authority control law development and flight testing); Ashok Agnihotri, Tech Fellow, Technology (control law development consultation

and program oversight); Nick Lappos, Chief Technology Officer (control law development consultation and program direction). At the National Research Council of Canada, Flight Research Laboratory, Ottawa, Ontario: Arthur W. Gubbels, Research Officer, Flight Mechanics and Avionics (ASRA FBW system development and flight test engineer);

0 10 20 30 40 50 60 70-8

-6

-4

-2

0

2

4

6

Eul

er A

ngle

(de

g)

0 10 20 30 40 50 60 70-100

0

100

Time (s)

Hea

ding

(de

g)

Fig. 23. Pirouette MTE – attitude response.

Xe-position (ft)

Ye-position (ft)

Start Point

Desired Circle Flight Path ---- ± 10 ft Circle ---- ± 15 ft Circle

Center Point

Fig. 24. Pirouette MTE – position response.

20

S.J.R.P. Carignan, Group Leader, Flight Mechanics and Avionics (safety pilot); Kris Ellis, Research Officer, Flight Mechanics and Avionics (Ethernet communications development and testing); Carl Jones, ASRA Crew Chief (ASRA aircraft systems maintenance); Michael Mullins, ASRA Instrumentation and Electrician (aircraft and FBW electrical systems development and maintenance).

REFERENCES

1. Schillings, J., Brown, H., Epp, J., Kim, S. K., and

Dreier, M. E., “Simulation of the Bell/USMC AH–1Z Helicopter Using COPTER/MATLAB/ SIMULINK® Analysis,” American Helicopter Society 58th Annual Forum, Montréal, Canada, May 2002

2. MATLAB: The Language of Technical Computing –Using MATLAB, The Math Works Inc., Natick, MA, 1997

3. Tischler, M. B., Cauffman, M. G., "Frequency-Response Method for Rotorcraft System Identification: Flight Applications to BO-105 Coupled Rotor/Fuselage Dynamics," Journal of the American Helicopter Society, Vol 37, No. 3, pg 3-17, July, 1992.

4. Christensen, K. T., Campbell, K. G., Griffith, C. D., Ivler, C. M., Tischler, M. B., Harding, J. W., “Flight Control Development for the ARH-70 Armed Recon-naissance Helicopter Program,” Presented at the Ameri-can Helicopter Society 63rd Annual Forum, Virginia Beach, VA, May 2007.

5. Colbourne, J. D., Frost, C. R., Tischler, M. B., Cheung, K. K., Hiranaka, D. K., Biezad, D. J., “Control Law De-sign and Optimization for Rotorcraft Handling Qualities

Criteria Using CONDUIT®,” Presented at the American Helicopter Society 55th Annual Forum, Montreal, Que-bec, Canada, May 25-27, 1999;

6. Shue, S. P., Corrigan, J., Wood, T., and Ewing, A., “Longitudinal and Lateral Control Sensitivity Damping Analysis for Larger (JHL) Rotorcraft in Helicopter Mode,” Proceedings of AHS 2009 paper, Grapevine, TX, May 2009.

7. Brown, H., Koelzer, H., Ruckel, P., Stepura, M., “Real-time Blade Element Math Model Delivered for USMC Flight Training Devices,” Presented at the American Helicopter Society 64th Annual Forum, Montréal, Can-ada, April 29 – May 1, 2008

8. Shue, S. P., Corrigan, J., and H. Brown, H., “Integrated Simulation and Control Tool – COPTER S-function Matlab Control Law Desktop Simulator,” Proceedings of AHS 2009 paper, Grapevine, TX, May 2009.

9. Mosterman, P. J., Prabhu, S., Dowd, A., Glass, J., Erk-kinen, T., Kluza, J., and Shenoy, R., Embedded Real-Time Control via MATLAB, Simulink®, and xPC Tar-get, Handbook of Networked and Embedded Control Systems, DOI: 10.1007/0-8176-4404-0_18, November 14, 2007

10. Gubbels, A.W., Carignan, S.J.R.P. The NRC Bell 412 Advanced System Research Aircraft – A New Facility for Airborne Simulation, Canadian Aeronautics and Space Journal, Vol 46, No. 2, Jun, 2000, p106-115

11. ADS-33E-PRF, 29 Feb. 2000, cage code 18876, “Aero-nautical Design Standard Performance Specification Handling Qualities Requirements for Military Rotor-craft,” http://www.redstone.army.mil/amrdec/sepd/tdmd/Documents/ads33front.pdf