Section
Table of Contents
Page Number Section ir List of Tables List of Figures Chapters , 1.0 Introduction 2.0 Overview of CONDUIT 3.0 Development of CONDUIT 4.0 Required Elements for problem setup 5.0 UH-60A Design Examples 6.0 Lessons learned during thesis 7.0 Conclusion References
List of Tables
Table 1: The design parameters taken from Tischler (Ref. 9) paper and CONDUIT solution.
Table 2: Delay parameters.
Table 3: Initial desiin parameters as provided by Tischler's paper with CONDUIT optimized parameters for the model following solution.
Table 4: The final values of the optimization constraints.
t i s t of Figures
Figure 1: Exanlple ADS-33 bandwidth specification Figure 2: Exainple of supporting information that is require for the ADS-33 quickness 17 / specification.
Figure 3: The handling quality editor provides a convenient set of push button tools that facilitate rapid problem setup.
Figure 4: The normalized distance criteria. 2 1 Figure 5: Distance algorithm calculation. 2 3 Figure 6: Bandwidth specification with a 0.6 design margin.
Figure 7: The CONDUIT environment.
Figure 8: Example of a Sirnulink block diagram 3 0 Figure 9: The RASCAL UH-60 helicopter.
3 5 Figure 10: Model following block diagram.
Figure 1 1 : UH-60A model following control law.
Figure 12: Specs used in ADS-33 control law design.
Figure 13: Handling quality analysis of Boeing's control laws.
Figure 14: Showing the bandwidth for the yaw channel using Boeing's design parameters.
Figure 15: Supporting plots for roll quickness handling quality specification.
< Figure 16: The broken loop frequency response for the roll channel for Boeing solution.
Firure .. 17: ADS-33 solution after tuned within the CONDUIT environment.
Figure 18: Yaw bandwidth supporting plots.
Figure 19: The supporting plots for the roll quickness specification for input signal 6nce it has achieved Level I.
Figure 20: Roll channel gain and phase margin supporting plot after tuning in CONDUIT environment.
Figure 2 1 : The model following specification.
Figure 22: Model following specification for the Boeing design parameters.
Figure 23: Supporting plot for the model following spec (pitch).
Figure 24: Supporting plot for the model following spec (roll).
Figure 25: Supporting plot for the model following spec (yaw).
Figure 26: CONDUIT'S optimized parameters for the model following solution.
Figure 27: Supporting plot for the model following spec with optimized solution (pitch).
Figure 28: Supporting plot for the model following spec with optimized solution (roll).
Figure 29: Supporting plot for the model following spec with optimized solution (yaw).
Figure 30: Position and velocity feedback loops for position hold example.
c Figure 3 1 : The position hold specification.
Figure 32: Windgust solution for minimized RMS position.
Figure 33: Time history plot of the helicopter's position for minimized W S position.
Figure 34: Supporting plot for actuator energy (roll) with saturation in I the actuator rate Figure 35: Medium RMS position hold solution. 7 8 Figure 36: Time history plot of the helicopter's position for medium RMS position. 79 Figure 37: Supporting plot for actuator energy (roll)) with saturation 8 0 in the actuator rate.
Figure 38: Large RMS position (minimized roll actuator energy). 8 2 Figure 39: Time history plot of the helicopter's position for large RMS position.
Figure 40: Supporting plot for actuator energy (roll)) with saturation 8 4 in the actuator rate.
Figure 41 : The trade-off between hover hold and actuator energy.
8 5
Chapter 1 '
Chapter 1 '
Introduction
1.1 Introduction Designing aircraft control systems to meet the formidable set of handling quality specifications as contained in the MIL-STD-1797A (Ref. 10) or ADS-33 (Ref. 1 1) can be a time consuming task. A control system that is designed to satisfj one or two key specifications may fail to meet the remaining criteria specified in the other handling quality requirements. Developing trade-offs that satisfy several requirements is a main aspect of the engineering discipline and the area of handling qualities is rooted in trade- offs however, the time required to perfonn a complete analysis handling qualities can be enormous, taking up to a week or more. It is impractical for an engineer to run a series of test cases to evaluate an optimal control system. The results of handling qualities often do not reveal an obvious way to improve the design. An engineer therefore uses control system design methods that involve shaping of frequency responses and time response verification while and not using handling qualities in the design phase. Only after much career experience could an engineer be expected to reflect back on the methods he has used , and provide a generalized philosophy on the methods that provide an optimal control system.
There is no single standard architecture (although many have tried to force one in order to use optimal design) and each control system design team seems to have its own standard method that is developed through the projects they worked on. As such there can be variability in control system architectures from company to company. The time involved in testing several architectures prevents rigorous trade-off studies of controller architectures.
Control system engineers have generally developed good designs that satisfy the minimum requirements. They have no way of knowing if this is the best design for the given architecture. There have been several optimal design techniques that often limit the architecture of the controller and as such have limited appeal to the industry engineers.
The con~plex nature of MIMO control laws especially in rotorcraft, which has the nature of highly coupled systems, generally prevents the engineer from seeing the trends in the control laws that would enable fine-tuning that would ensure the "best" design was found.
These aspects of control system design and handling qualities analysis have been under study for the past several years at the Rotorcraft and Powered Lift Branch (AFR) of the Ames Research Center. A key result of these recent efforts is the CONDUIT tool.
CONDUIT unites the fields of handling qualities analysis and control system design into one environment. CONDUIT takes it's name from CONtrol system Design and evalUatIon inTerface. The key words from the acronym are design and evaluation , interface. These words address the philosophy behind the program. Unlike other control system theories that dictate the architecture of the controller that might conflict ,\rith experiences and knowledge, CONDUIT makes no assumptions as to the "right way" to build a controller. CONDUIT is a powefil tool that allows you to evaluate, colnpare and tune your control system. It is designed to evaluate the architecture that you provide C to the system.
The chapters of this thesis will provide a detailed outline of the features of CONDUIT, along with designs performed on the model following control system of the UH-60A Blackhawk helicopter.
1.2 Research Objectives The research objectives fall into two main categories: the developillent of a control system design tool that would allow rapid evaluation and design of control systems against handling quality criteria; use of this tool to evaluate and tune Boeing's lllodel following control laws for the RASCAL research helicopter at NASA Ames Research Center.
The development of the tool, CONDUIT, came partly out of the desire to facilitate the analysis of RASCAL handling qualities and incorporate this as part of the design process. The design of CONDUIT focused on the philosophies of providing a visual environment that provided powerhl and complete anaIysis combined, with an easy-to-use interface that allows for push button setup and evaluation. The second set of .
key philosophies was a flexible setup area that allows the user to create any architecture for their controller with a minimum of restrictions.
Three RASCAL design examples were used to demonstrate CONDUIT to find weaknesses in CONDUIT, and to develop strategies to best interact with the C O N D ~ I T system. These designs were used throughout the development of CONDUIT as test cases to verify the algorithms. Also the use of a system that allowed the design to satisfy handling quality requirements found that several specifications would hinder the tuning of a design. Information concerning the proper use of specifications in these designs provided a strategy that allows us to rapidly tune and analyze control system design.
Chapter 2
Chapter 2
Overview of CONDUIT
2.1 Statement of Purpose This thesis addresses the concerns of integrating the areas of handling qualities with control system design. Providing a powerful and flexible environment was a major component of this thesis work along with developing tools that provide detailed analysis of the control system. CONDUIT'S ability will be featured in three design cases of tuning the control laws for a model following RASCAL control system. Through these design cases, strategies and techniques will be developed for operating CONDUIT in the most effective way.
2.2 The Philosophy of CONDUIT CONDUIT was developed to bring handling quality requirements into the control system design process. The method of building the system is based on a few key philosophies which provides the foundation for making a useful tool for control system design.
, CONDUIT has been laid out with three principle philosophies: the first principle was that CONDUIT should be powerful by automating all handling quality calculations.
n e time spent calculating a set of handling qualities specifications can be enormous and is one of the key reasons that companies don't use the specs for design.
The second principle stresses that CONDUIT remain flexible. CONDUIT \ifon't dictate the design of the control system. CONDUIT is required to be flexible so , that it doesn't discourage engineers by limiting their control system architectures. The key is that CONDUIT will evaluate the design of the control system and help tune the control system. CONDUIT will not constrain the design of the controller. The CONDUIT program provides the flexibility that allows the engineer to build to any control system architecture desired. The tuning features will work with the architectures given that the parameters selected to tune the system indeed produce an effect on the system.
The third principle is to make the program easy to use. CONDUIT requires a push button environtnent that allows for easy setup and analysis. The program needs to have the ability to communicate a large amount of information with only a few key strokes. The idea is to provide information to users so that they can understand the system and trust the results that the computer provides.
2.3 The Features of CONDUIT The entire control problem setup is done in a Graphical User Interface (GUI) environment that allows the control system engineer to perform rapid set up and analysis.
Providing the user with an in-depth understanding of their control Ipws is crucial, so CONDUIT provides supporting figures for all calculations that go into handling qualities analysis.
The major problem with the previous prototypes of CONDUIT was the amount of knowledie and effort required to setup a specification. Hundreds of lines of code in various languages were required for each problem and then it was tied only to that control system architecture and only for that setup.
The CONDUIT environment uses MATLAB (Ref. 6) as the arithmetic engine of the program to manage all the control system functions. All control laws are entered in MATLAB's Simulink environment. This provides a great deal of compatibility with corllpanies that have developed control systems with MATLAB. All graphs and analysis plots are in color with use of MATLAB.
The block diagram is the symbolic representation of the mathematical dynamics of the aircraft and control systems. The block diagram is generated in the Simulink environment. CONDUIT provides the user access to the Simulink environment as well as irnporting Simulink files generated in MATLAB.
The handling qualities specifications are the key parameters that drive the whole system. The specifications provide both an evaluation of the control system as well as criteria that drives the optimization routines for tuning the system. Handling quality specifications such as ADS-33 for Military Rotorcraft and MIL-STD 1797A for fixed wing are charts that qualify aircraft performance into 3 regions: Level I - implies that desired performance is achievable with no more than minimal pilot workload, Level I1 - 8WOSlib:Bandwith & Time Delay All Other MTEslUCE>l {Divided (P&R) Figure 1 Example ADS-33 band~vidth specification.
the pilot the mission to be completed with an increased workload andlor some defTadatiOn in pe~formance, and Level 111 - implies the aircraft can be controlled but that the rrlission cannot be successfUlly co~npleted (Ref. 7). An example of ADS-33 handling specifications is provided in figure 1.
The specification scripts are structured in nodules that are self contained. This I approach allows for the simple addition and modification of the specifications by the user.
Specs are easily manipulated in the CONDUIT GUI environment. Specification setup is a rapid process with little knowledge of computer code required to implement the specs. A master editor for the handling qualities makes setup easily performed. The axis and the boundaries can changed with the mouse. This gives the user the advantage of custo~nizing specs and running "what i f ' scenarios to comprehend elements of the control law. CONDUIT gives the user the ability to relax specification boundaries, that can't be achieved with the current aircraft.
Most engineers approach any new tool with a healthy eye of skepticism. Many programs that promise the answers to complex engineering problems go unused unless the engineer has confidence in the answers. To gain confidence engineers require proof, a way to validate the calculations, and the approach to calculations. They won't use an answer they can't justify. That is why CONDUIT features supp01-ting plots that are contained in the specifications modules. These plot are produced with the click of the mouse and provide a series of plots that tell the user where the data point on the specification came from. The user then has confidence in the answers that CONDUIT produces.
After the user analyzes the performance of the aircraft at one set of design parameters it comes time to improve the control system design. However it isn't always clear how to proceed. To help the engineer tune his given control system a state of the art .
engine is integrated illto CONDUIT. The CONSOL-OPTCAD optinlization software is a FSQP (Frequency Sequential Quadratic Program) algorithln for multi-criterion optimization. The power of multi-criterion optimization Illo,f~s for the tuning of several design parameters while optimizing to several design
Chapter 3
Chapter 3
Development of CONDUIT
3.1 Previous FVork Done The early development stages of CONDUIT began in a joint program between A~nes Research Center and the University of Maryland and evolved through many stages that took key contributions from several people during its over five year development. A primary contribution came from professor Andrk Tits of the University of Maryland in the form of CONSOL-OPTCAD (Ref. 2). This program although separate from CONDUIT is used as the optimization engine that provides the ability to tune complex control systems.
The mating of MATLAB with CONSOL-OPTCAD to form the first generation of control system optimization developed by Michael Fan and Andrk Tits. Then a graphical display of the handling qualities was added by Gil Yudilevitch. This later design tool although somewhat difficult to setup contained the first concepts later evolved in the CONDUIT program. The work done in this environment used only the UH-60A model following control system and had no possibility to change to different problem without , months of work. The problem was cumbersome since the use of multiple copies of the block diagram needed to be used. Failing to keep all files updated presented the risk of different models being used in different types of specs without the user realizing this.
l,u,,.cr.er the main purpose of CONDUIT was born out of this work: The combining of handling q u a l i ~ specifications into the control system design phase.
The next generation of this code was shaped by Patrick Potter, Chujen Lin, and 3lclrk Lehene. Their work placed a GUI interface , named GIFCORCODE, over the work I done by Gil Yudlevitch. Although this allowed for the running of the CONSOL- OPTCAD optimization engine in a GUI environment as opposed to the text commands in the work done by Gil, it didn't allow for any increased level of ease or flexibility in the problem setup. That was still in the form of lengthy code that would need to be rend, understood, and altered by any user. Implementing a new problem in this program could take weeks or months.
Using the system Gil Yudilevitch had set up, Patrick Potter was able run different dcsign studies on the UH-60A problem. By swapping in the state space model for various flight conditions a preliminary use of CONDUIT was being developed.
3.2 K e y contributions of this thesis The work perfonned in developing CONDUIT over the past year is the focus of this thesis. The elements that have taken work previously co~npleted on this project and transfonned it into a releasable project will be highlighted in the following sections. The incorporation of the philosophies stated at the beginning of this paper shaped the design and layout of the system that made it powerful, flexible and easy to use. The major contributions of this thesis come in the areas of: continuous to digital block diagram conversion, easily altered modular specification, rapid setup and design, a normalization I algorithm, robustness in the design process, and a new program environment.
3.3 Continuous to digital block diagram conversions -- "digcon"
The aircraft and control systems for use in CONDUIT are modeled in Simulink.
It is this environment that the architecture of the controller is laid out, although a separate / program, CONDUIT incorporates the Simulink environment within it.
In keeping with the philosophies of providing an environment that makes for an easy problem setup and rapid analysis of the handling quality specifications, it is necessary to perform the time responses in the digital domain. Typically performing time response calculation with Simulink block diagrams in the continuous domain takes several times longer than the same response done in the digital domain would require. The effect of this on an optimization process, that requires hundreds of time domain sin~ulations, would be to bring it to a halt. Prototypes for CONDUIT used two copies of the block diagram, one in the continuous domain and a duplicate in the digital domain. This allowed for rapid evaluation but risked the chance that discrepancies might be made when altering one and not the other. The time involved in having the user work with several block diagrams and maintaining their consistencies made the setup process more taxing and left an opportunity for errors.
To remedy this, a function (C program) written for use in MATLAB converts all the continuous linear blocks in the architecture to discrete linear b l o ~ k s . A separate block diagram with the digital components is generated and used for all time response based specifications. The conversion method decided on was Tustin's method. Sample time is set and the conversion and simulations are run at this sample time. The program can be used on any Simulink block diagram and can be called as a function from within the MATLAB environment. The function is titled "digcon" (digital conversion). Calling this function generates a Simulink discrete block diagram in the form of the continuous diagram Y for the sample time used. This provides a significant increase in speed for all time response functions over continuous diagrams. The power of this function is that it leaves the nonlinear elements in the diagratn so that saturation and other nonlinear effects can be seen in the discrete diagram. A conversion of the end-to-end response to the discrete domain would eliminate the nonlinear effects.
3.4 Specifications Handling quality specifications are the driving force behind CONDUIT. They provide the unique feature that allows for the control system to be designed to pilot ratings. Control systenl design is usually done with methods that have to do with frequency response shaping. With CONDUIT the engineer can actually use handling qualities as the design goals. The implementation of specifications in the CONDUIT environment is the core of the system. CONDUIT supports the direct incorporation and tuning of handling qualities in the design process.
The handling qualities specifications are mainly generated from standard publications such as ADS-33 or MIL-STD-1797A . Additional specifications can be created by the users to provide design criteria to investigate issues specific to the project or just general criteria that enforce colnmon requirements; crossover frequency and actuator energy for example.
The specification is a key element of CONDUIT. All designs made are intended to meet the specifications, so handling quality specifications are crucial to developing the # correct and optimum design. The two key elements that they need to possess to keep the spirit of the design are the ability to implement them easily and, more importantly, to see what they are calculating and how they influence the design. The key elements of the specifications are discussed in the five following sections.
CONDUIT has the specs setup as a series of modules (provided or user defined) that define the geometry of the chart, perfonn the calculations required for the specifications and finally generates supporting plots and data that justify the results. The module is chosen when you wish to analyze that specification. The setup is easily perfonned in a GUI environment..
The borders or splines define the boundary between the sections of the Level I, two, and three regions. A new feature added during this thesis was the ability to move the splines so that the requirements used in the optimization could be altered quickly and visually. The mouse can move boundaries to drive certain specs harder and relax other specifications that may be limiting the design process.
The first thing that needed to be done was to turn the specs into modules that could be added and removed according to the designer's desires. Having this done effectively required an area to choose the specifications from. This area is called the library. Here pictures of every spec are stored in sections that separate the various types of specifications. The user can scroll through and click with the mouse o n the specifications that the user requires for the design. The new spec will be added to the handling quality window. The handling quality window is the primary work region that chosen specs are displayed in. All setup, interaction, and infornlation occur in this window.
Providing the user with detailed information of how the control system is Z performing in an easily read presentation is part of the strength of CONDUIT. An important feature to the CONDUIT program is the supporting plots contained in each of the specifications. This allows for intensive analysis of the calculation of the spec. There is no blind trust that is required for the results. Each of the results is justified with a series of plots and data that reinforce the calculations involved in the specification.
Supporting plots display the process involved in generating the data for these specifications. This feature is a powerful and required feature that allows the engineer to trust and understand how the results are generated. It removes the tedious repetition of calculations that would be required to double check the results with each answer CONDUIT provided. The supporting plots are activated by clicking on a spec after results have appeared on the specifications. A supporting plot is a window which shows the graphs and useful information that went into the calculation of the spec. Figure 2 shows an example of the graphs used in generating the data for the quickness handling quality specification.
3.5 Handling Quality Editor I One of main appeals of CONDUIT is the ease in which the problems can be setup in the GUI based environment. A key tool that facilitates problem setup is the handling Figure 2 Example of supporting infomlation that is require for the ADS-33 quickness specification.
I Figure 3 The handling quality editor provides a convenient set of push button tools that facilitate rapid problem setup.
quality editor. This window (Figure 3) allows the user to connect the spec to the block diagram. The first column in the editor provides a list of input ports that are taken from the block diagram. The inport indicates the starting control path for the specification.
This either represents where an input signal enters the block diagram for a time simulation t / based spec or it represents the input for the frequency response calculation. The three rows allow for up to three channels or cases to be run on a single spec, typically pitch, roll, and yaw or three different signals into the same channel on a time specification. The second and third columns allow for either one or two out ports. These out ports indicate the other end of the control path from the in port. Frequently specs will require two outports, i.e., rate and position from a single input signal. For ease in setup of the in and out ports the editor provides a pull down list of both the port numbers and names as labeled on the block diagram.
The fourth colun~n allows for switches that alter the control paths in any fashion that the designer can invent. Up to four switches can be thrown at once, with the understanding that a single switch can be used to throw multiple switches. With this ability the designer can produce very sophisticated block diagrams.
The next column is used only in time domain specifications. This column allows the user to designate the input signal vector defined in the initialization file. This vector represents a time history input such as pilot cornmands or wind gust perturbations.
The last user defined column allows the user to specify the symbol being used in the diagram. This feature allows the user to maintain a consistent notation for similar control paths. To the right of the last column is an area that indicates the horizontal and vertical values of the that channel for point data only. The user when needing to know the exact x and y position of a data on a handling quality chart can refer to these columns.
Line data such as time histories will not provide a value here. The bottom of the spec builder provides information such as the axis values that can be edited as well as a list of options that are~pecific to the individual spec. The lower right contains a series of push buttons. The long button allows the user to set the optimization to one of four options: hard constraint, soft constraint, objective function, or check only. This is used to specify the priority during the optimization. The next row of buttons provide access to series of features.
The update button sets the entered parameters to the spec once they have been entered by the user.
The info button opens a window containing information specific to the spec. The infonnation contains a detailed history of where the spec comes from as well as the purpose of the specification. Also contained in the infonnation box are details on how to setup the spec ensuring units and other details are correctly set by the user.
The button marked D.A. allows the user to map points on the spec and check the calculated normalized distance calculated by the distance algorithm. This allows the user to verify that the distance algorithm is converting the proper normalized value being compared to the competing specs.
The close button simply closes the handling quality editor. Failure to update new entries before pressing this button will result in the loss of new data. ' 3.6 Distance Algorithm The distance algorithm is the key element that allows for the tuning of the system.
The optimization engine performs the comparisons in-between the handling qualities specification. In order to perform the comparison a standard scale had to be used in which all of the specs could be rated. The boundaries are obviously the starting point for measuring the rating of the spec. It seemed obvious that specs that had results resting on the boundary of Level I and Level I1 regions would all be equal, likewise all data located on the Level I1 I 111 boundaries would be weighted equally between all of the specifications.
With these two starting points as a scale for cornparing the specs the following rules were developed: The value given to these regions will be a 1 for data on the Level I 1 I1 boundary. The value of 2 is given to data with the values lying on the border of the Level I1 and I11 regions.
The distance algorithm makes comparisons during the optimization of the specifications in a single problem. Normalizing the value of specs against other specs is crucial in evaIuating the overall performance of the controller and aircraft. Looking at the bandwidth and quickness spec in Figures 4 (a) & (b) the properties used in determining the algorithm in the distance algorithm can be determined.
QK04lih:Quickness (Roll) BW0Slib:Bandwith & Tirne Delay A l l Other MTEs c t q l l Other tvlTEs/UC:E>l {Divided (P&R) Figure 4 The normalized distance criteria.
a) All specifications that have data located on the level one, level n\o boundaly are rated equal in perforn~ance to all other specifications that have the data on this boundary. (b) Similarly the data located on the level two level three border will be rated equally across all specs.
Examining the bandwidth spec there are two borders that separate the different regions on the plot. A value of one will be given to any data lying on the border that separates the Level I and Level I1 boundaries. Likewise a value of two will be given for data lying on the border separating the Level I1 / I11 areas on the plot. Using these two marks the res't of the algorithm was based. This basic rule implicates that the drop from the Level I / I1 border to a Level I1 / 111 border is an equal reduction in performance or handling qualities for all the specs. This holds true for the development of specifications that the change of spec from one border to the next is equal to the change from a border to the other in all other specs. With this normalization all specs can be measured in the distance separating the borders and scaled to the value of one and two. The complexity of the algorithm goes into determining how to measure the borders to the data point. Having the distance algorithm detennine this distance for a wide variety of spec shapes, the scale is performed to the following series of rules and calculations. The charts in figure 5 are used to depict the processes involved in generating the scaled values. The distance algorithm calculates the distance of the closest point on the spline to the data point (dl).
From this line between the data point and the spline the closest distance is searched for within 30 degrees of this spline. This was done so that line distances were taken from the same direction and to avoid problems that arise in specs that have "U" shaped splines or 90 degree bends in the spline. This second is labeled d2 in figure 5. The width of the Level I1 region is d3. This is found according to equation 1,2 and 3.
d3=d2-dl : for d l < d2 (Level I) d3=d2+dl : for d l , d2 < d3 (Level 11) Eqns. 1 , 2 and 3 d3=d1 -d2 : for d l > d2 (Level 111) BV$O51ih:Ban1:jwitt-1 R Time Delay BVliO5litj:Bandr>-,iitk1 8. Time Delay -411 Other ~$lTEsilJiIE::-l {Divided (P&R) fill Ott-ler M T E ~ ~ I ~ c E : : . ~ [Oi\>ided ( p & ~ ) F i r 5 : Dis!ancc. algori~ll~n calculation. (a) The distance algorithm calcu1atc.s the distance of the point to the nearest point on the Level I / I1 spline. (b) The distance to the secolld spline is then chosen from a point that is nithin 30 degrees of the first point. (c) The normalized distance is the difference between the closest points on the two spline$. (d) Splines extend out from the specification at the same angle that they vector data are determined b ! . ths ..\\.orst point" of the vector.
approach the edge. ( s ) Specifications that use The value for d3 is approximate since the d l and d2 lines don't always lie on top of each other. The normalized value is calculated according to equations. 4, 5, and 6, for the Level I, 11, and 111 regions respectively.
Eqns 4,5, and 6 The specifications that use vector data instead of point data, the algorithm takes the point on the vector data that has the worst value and uses that as the data point.
3.7 Design Margin With all math models being an approximation of some degree of the actual system or aircraft it is always better to incorporate a level of robustness so that any inaccuracies between model and aircraft don't reduce the aircraft to a Level I1 from a Level I. To keep CONDUIT from producing a design that rides on the border between Level 1 and Level 2 a design margin can be incorporated into the handling quality specifications.
As explained earlier the weighting of the specifications against each other is based on the distance between the Level I and Level I11 areas (the width of the Level I1 region). This weighting distance nonnalizes the specs between each other. This normalizing length is # also used in the calculating the design margin. The design margin represents a region that extends into the Level I region by factor of the normalized distance. This is represented on the normalized scale that possess a value of one on the Level I, Level I1 border and a BW03lib:Bandwidth & Time Delay All Other MTEslUCE=I/Fully Attended (Pitch) Figure 6 Bandn-idth specification \vith a 0.6 design margin.
value of two on the Level 11, Level I11 border. The value of the design margin represents this value on this normalized scale. For example a design margin value of 0.9 produces a region of ten percent of the normalized distance, for that spec, extending into the Level I I region. Figure 6 demonstrates the a 0.6 Design Margin on a Bandwidth and phase delay spec. The varying width of the Level I1 region is reflected in the distance that the design margin (green line) extends into the Level I region.
3.8 Environment A considerable change in CONDUIT over the previous prototypes is the centralized integrated environment in which CONDUIT has incorporated all the function and features into. CONDUIT uses a main window with pull down menu and iconified buttons that allow the user to trigger the most frequently used features of the system.
The desire in CONDUIT was to make easy-to-use tool that didn't require a significant knowledge of programming to setup and analyze problems. A key advantage over previous versions was that any modification required the user to read through pages of code within several different files, written in different languages and then enter a significant nuinber of lines of new code. Even to change the order or the nuinber of specs it would be a tedious undertaking. CONDUIT allows the specs to be manipulated via the mouse. The addition, modification, and removal of the specifications is easily performed by the "click" of a mouse. Setup is performed with pull down menus that allows the user to install specs with easy push button features. This was done without compromising the flexibility of the system and is what allows it to be so powerful. With a setup and evaluation of an existing block diagram only taking a few hours. CONDUIT is also a very visual environment that displays the information in plots and graphs that aid in the rapid understanding of the control system. It gives the user the ability to see what is happening with the controller. Figure 7 shows a collage of the CONDUIT interface. Multiple investigation into varied configurations becomes possible within a significantly shortened time period over existing conventional methods.
Figure 7 , The COKDUIT environment.
Chapter 4
Chapter 4
Required Elements for a Design Problem
4.1 Aircraft Model The aircraft model is the central part of the problem in CONDUIT. The model and control system dynamics are developed in the Si~nulink environment. The complexity of the model is left to the prerogative of the engineer, there is an obvious trade-off between accuracy and con~putational time. The Sirnulink environment supports sophisticated nonlinear designs that can be expressed in a graphical environment that is used in CONDUIT. Figure 8 is an example of a simple block diagram used for an XV-15 deinonstration problem that is released with CONDUIT. There are a few minor rules that must be followed to ensure a formatting that will be accepted by CONDUIT. The rules pertain to the selection of mnemonics for the design parameters, switches, and input signals.
An initialization file must be created to support the block diagram to store , information that couldn't be included in the model. This file contains the definitions for all the key variables, functions and defining mnemonics. The initialization file is comprised - + J Simplified XV-15 Roll Channel aileron rate Control Law Foward Flight) --+J phi Created by h a r k R. Morel January 17. 1998 aileron - - P rad/sec C p [deglsec] - roll rate resp [radsec] zero
*
open loop fdbk Figure 8 Example of a Silnulink block diagram.
of: default parameters that define the input signals that will be required for time domain simulations; modeling data; and the initial value of the switches.
4.2 Handling Quality Specifications , Specifications are key to finding a solution. Once the user has entered the model into CONDUIT they need to select specifications that will allow the user to analyze and improve the controller. The user needs to pick specifications that will provide a complete picture to determine if the controller and aircraft perform as a Level I aircraft. Choosing these specifications is left to the user depending on what aspect of the system is of interest. Once the user has decided which specifications are required, specs can be chosen from the pull down library window with the mouse and be added to the handling qualities window. Once here the specs can be setup and modified by clicking on the individual specification and opening the handling quality editor. The specifications work between ports in the block diagram. Menus provide the information required to 'wire' the spec to the block diagram. The editor allows the selection of the in and out ports, any breaks in the channels that would be necessary, and signals that need to be passed into the specification.
The splines can be moved to suit the desired design by the user. Once the specs have been chosen a robust margin can be selected to prevent the optimization engine from designing to the border.
4.3 System Evaluation , Once the user has set up the aircraft model with controller and chosen and 'wired' the specifications it is possible to proceed to the evaluation mode of CONDUIT. In the initial phase of the evaluation mode all the design parameters are set to the value 1. These are arbitrary values and can be replaced by other values that might be known for a rough or baseline design. Evaluate the design with either default or chosen parameters. Within a few seconds to a few minutes, depending on the complexity of the model and the number of specs the handling quality window will display the calculated value of the specifications,. Typically the default values will give poor results. By selecting the spec a supporting plot can be shown that illustrates why the value is calculated to be that way.
Since the optimization can't always find solutions when starting at really bad results it is typical to use classical techniques and intuition in conjunction with the results supplied in the supporting plot to quickly determine a set of design parameters that will produce a solution that might be in the ball park of a reasonable solution. CONDUIT can be used in this fashion quite productively by allowing the user to tune the parameters by hand until a solution is found. Used in this way the tool represents quite a bit of power when other methods require a week to run a new set design parameters through the system. The user can run 'what if scenarios by changing different aspects of the control system and almost instantly seeing the effect those changes have on a set handling quality specifications.
4.4 Starting the Optimization The CONSOL-OPTCAD optimization engine allows the user to find the best design in a region. Although the system can tune be tuned manually with the use of classical control techniques and the supporting plots, this is not always easy. In problems that have coupling or multiple feedback gains with forty to fifty specifications and 12 design parameters it becomes difficult to determine which design parameters and in which combination of values will produce an over all improved design. This is when it I becomes necessary to use the optimization engine.
The optimization process optimizes according to constraint type chosen in the handling quality editor. The constraints can be divide into three priorities, these are hard constraints, soft constraints and objective functions. The hard constraints must be satisfied for there to be a solution. The soft constraints are used to find a solution by givini the program targets to be met. The objective functions are used to help pick out the optimal solution by minimizing that specification. The program strives to satisfy these specifications in three different phases. Optimization conducted in three phases. In Phase 1 the program moves toward satisfying the hard constraints. CONSOL-OPTCAD adjusts the design parameters to achieve Level I for all the specifications that were set to hard constraints. Typically hard constraints are chosen to be the specs that guarantee stability or those that are of particular interest to the user for this problem. These are specifications that need to be nlet with no exceptions. In phase two CONSOL-OPTCAD attempts to satisfy the specs, that are set to be soft constraint or objective functions into the Level I region. In this phase these two types of specs behave in a silnilar matter.
These specs are ones that you would like to meet Level I but are possibly willing to co~npromise if there is no solution. These types of decisions are why this is an interface tool for the engineer and not a "turn the crank" all purpose solution. If all the hard constraints, soft constraints and objective function specifications meet the Level I area then the optilnization engine reaches the third phase. In the third phase the objective functions drive the data points for the specification further into the Level I region until a optimal design has been reached. This design is normally characterized by a local minimum.
Chapter 5.0
Chapter 5.0
UH-60A Design Examples
5.1 Introduction to Design Problems The following designs deinonstrate the use of CONDUIT with the Sikorsky UH- 60A Blackhawk helicopter. The Ames Research Center operates a Blackhawk research helicopter under the RASCAL (Rotorcraft Aircrew Systems Concepts Airborne Laboratory) program (Ref. 1) (Figure 9). Boeing Helicopters has designed a model following control law using conventional design techniques. In an effort to si~nultaneously validate the control laws designed by the engineers at Boeing and the algorithnls in CONDUIT the Boeing ADOCS control laws for the RASCAL helicopter (29-69, Guls~nan) was run through a design session with CONDUIT. Designs are performed by developing a traditional architecture and implementing design parameters; variables that can be used to tune the control laws. Design parameters can be used as gains, pole or zero locations, transfer function coefficients, or any number that represents a value in the block diagram. The first two problems use 12 design parameters, 9 feedback gains, and 3 model parameters for the pitch, roll, and yaw loops.
Figure 9 The R4SC.AL UH-60 helicopter.
The first problem shows how the RASCAL architecture can be tuned to an optimal design that satisfies the ADS-33 handling qualities requirements. The second design problem focuses on the model following architecture and produces a solution that allows the helicopter9; end-to-end response to track a second order transfer function model.
The third design problem demonstrates CONDUIT'S ability to perform trade-off analysis between competing specifications.
5.2 Blackhawk Design for ADS-33 Requirements The first design problem addressed in this paper is concerned with establishing a baseline set of design parameters that will allow the helicopter to function in accordance with ADS- 33 control laws (Ref. 11). This set of design parameters will establish a confirmed standard that can be referred to in future designs and specialized optimizations.
The Blackhawk helicopter requires a baseline control law that will satisfy ADS-33 handling quality specifications. In this design problem, the model used in the UH-60 illode1 following control system architecture is allowed to change rather than remain fixed.
This is done because this problem focuses on the end-to-end response and the resulting handling qualities as the important elements.
The architecture consists of a model following design. The model following architecture will be briefly reviewed here with more detail describedin section 5.2. The simplified block diagram (figure 10) will serve to illustrate the concept behind this model following design. Equations in section 5.2 prove the block diagram reduces to the model M if P - ~ is truly the inverse of the plant. The model following control system uses an approximation of the inverse plant to cancel out the plant dynamics and uses feedback gain to reduce the mismatch between the model and the plant. Assuming a good model is used, a detailed analysis of how the aircraft will perform to all the specifications is not clear to the d e s i h e r without calculating each one in CONDUIT or by hand. The model employed by the engineers that developed this system is a second order transfer function that exhibited good characteristics and tried to alter the aircraft's end-to-end response dynamics to meet this model.
The first order inverse plant approximation (P-1) was created first by matching a zero over first order curve fit of the complete frequency response of the pitch, roll, and yaw channels of the aircraft. The transfer function was then inverted and placed into the P-1 block in figure 10.
- - Model P -l P inverse aircraft plant dynamics
+
- -.
H H feed forward feedback Figure 10 hlodel following block diagram.
This first design problem was to tune this architecture (including model) so that the design meets the ADS-33 specifications. Figure 1 1 shows the actual block diagram used in this model. The block diagram consists of a 14 degree of freedom state-space representation of the U H - 6 0 A helicopter dynamics (Ref. 3). The inverse plant dynamics (P-1) are the inverse low order transfer function fits of the higher order plant.
Feedforward and feedback loops are summed through the feedback compensation block (H). The feedback compensation consists of a PID controller using the 9 feedback gains ( 3 three for each of the pitch, roll, and yaw channels) as 9 of the twelve design parameters. The remaining three design parameters make up the second order model transfer functions.
The second order inverse of the plant dynamics was obtained by taking frequency data from the plant and crossfeeds together. These data were fed into Navfit, a curve fitting utility of CIFER that produced the transfer functions in equations 7 through 10.
The transfer function fit for the pitch channel is given as: 3.20647 - 4 = Eqn. 7
6 ( S + 0.58468)(s + 1 1.770)
The transfer function fit for the roll channel is given as : 16.6734 - p = Eqn. 8
6 ( S + 6.1 178 + 3.397891')
The transfer function fit for the yaw channel is given as : r 397.6 16 - - - Eqn. 9
6 ( S + 592.64)(s + 0.79536)
Figure 11 UH-60A model following control law.
It is obvious that the yaw chamel has an unusually high pole and gain. This indicates that the first order inverse will be adequate for the plant inverse. Previous papers (Ref. 8) indicate that the first order is adequate for the Yaw channel. The first order expression is given as: Eqn. 10 The integral of these three transfer functions (converting q/6, p/6, and r/6 to 016, $16, and ~ 1 6 respectively) are implemented into the P-1 block for the block diagram to be used in CONDUIT.
The specifications used in this design example come from both ADS-33 (Ref. 11) and those developed at the Ames Research Center based on classical control theory. The specs chosen were: crossover frequency, actuator energy, eigenvalue stability, gain and phase margins, bandwidth, quickness, coupling, and wind gust. Figure 12 shows the specs that will be used in this and the next example design problem. The specs are going to be ranked by their optimization type (hard constraints, soft constraints, and optimization function). The eigenvalue stability specification (12a) uses the real part of the roots of all the poles for system. It drives them into the left hand plane to ensure over all stability of the plant and controller. The Level I1 region on this spec was made very small to enforce the idea that either the roots are stable (Level 1) or not (Level 2).
The gain and phase margin spec (12b) also enforces a stability margin using 6 dB of gain margin and 45 degrees of phase margin. This spec is u s e h l k comparison to other similar specifications that measure stability (i.e. damping ratios) since this is smooth and continuous during the optilnization phase. Both the eigenvalue and gain and phase margin E l G l lib: Eigenvalc~e Stability (P,II Sta.tes)
- 20 i t 2 o o
Real Axis (a) J , L - I I B'AtO5lih Bar?d\i!lti-I & Time Delay BW0711t:i Bandwidth & Tirne Delay A l l Otiirlr I\.,lTEs/ULE-.1/Dioided (P&R) P,II Other M T E s ( Y a ~ j ) 0 2 4 0 2 4 Bandwidth [radlsec] Band4+vidt h [radlsec] (c> -, 8 # I I C Y , . ,, ,.._. L""1 WY,r)4lib:Q1~ickriess (Roll) OKll3l1b:Quickness (Pitch) All Other IvlTEs ?,I1 Other MTEs QKrJElib:Quickness ('law) All Oti-ier MTEs 3 4 5 0 i 4 time [sec] t ~ m e [ s e c ] - - W G S l lib: Wind Gust 0 2 0 40 time [sec] (0 A E N l lib: CROl lib: Actuator "Energy" Specification Crossover Frequency 0 1 2 3 4 5 6 7 8 9 1 0 0 1 2 3 4 5 6 7 8 9 1 0 Total P,ctuator "Energy" [r.Jr~rrnal1ier.i-F;ate"2] Crossolder Freqrrency [rad/sec] (el Figure 12 Specs used in ADS-33 control law design.
(a) eigenvalue stabilic, (b) _gain and phase margin. (c) bandwidth, (d) quickness specifications, (e) coupling specifications. (0 \vind gust specifications. and (g) cross-over frequency and actuator energy specifications \vere chosen to be hard constraint in the handling quality editor. These specifications guarantee stability and that no design ~bould be accepted that had compromised stability.
, The bandwidth and phase delay spec (12c) ensures that the end-to-end control system is responsive to a certain frequency. Bandwidth is a measure of responsiveness, too little, and the aircraft feels sluggish. The higher the delay in the system the Inore bandwidth is required.
* The quickness specification (12d) is a measure of agility of the aircraft. The requirement ensures that the aircraft is more agile for small attitude changes and will allow for less responsiveness for larger attitude changes.
Helicopters typically have a large degree of cross-coupling between the channels.
It is usual for there to be a significant amount of motion in other directions when a command is placed into single direction. The coupling specification (12e) help minimize the amount of coupling in the off-axes.
The wind gust specifications (12f) enforce a level of stability and damping in the feedback loop. A simulated wind gust should damp out according to the time response envelope of the specification.
The bandwidth, quickness, coupling, and windgust specifications were set as soft constraints since these requirements are not as crucial as stability. It is possible that a Level I1 solution in some of these specification might be accepted if limited by the aircraft.
The two specifications for optimization (12g) are crossbver frequency and actuator energy. These two specifications are complimentary. A high crossover frequency usually allows more noise through the system and forces the actuator to work harder. Driving down the crossover frequency drives down the actuator energy. These specifications were set to objective hnctions in an effort to minimize the values and reduce any extra actuator energy not required for a Level I design.
A design margin of 0.9 was selected to ensure a minimum Ievel of robustness. The I 0.9 design margin extends the Level I1 region ten percent more into the Level I region so that solution won't be a borderline Level I / 11, solution.
After the specifications were setup, CONDUIT was placed into the run (analysis, optimization) mode. The design parameters were initially set to the Boeing default parameters and the analysis was run (Figure 13). Unless specified otherwise, the data in these figures use the yellow triangle for pitch, the green inverted triangle for roll and the black diamond for yaw. The time response vectors use the same color code for pitch, roll, and yaw as the point data and are always in the order of pitch, roll, and yaw as the specs appear from left to right in the following figures. The example of this order is shown in the wind gust specification. When the Boeing ADOCS control laws are tested against the ADS-33 specifications it is clear that the aircraft quickness is not sufficient in the yaw and roll channels and barely so in pitch. The yaw bandwidth is also solid Level I1 as seen in figure 14, the supporting plot of the yaw bandwidth for the yaw bandwidth calculation, The bandwidth corresponds to the frequency of the model transfer hnction in yaw. It obvious that the design parameters dp-Mpsi of the yaw model will need to increase. To examine why the quickness specification didn't meet the requirements for the small yaw inputs; figure 15 contains the supporting plot for the small input yaw channel.
, Next CONDUIT was exercised to optimize the design parameters so the controller would meet all the specifications and drive down the crossover frequency and P E N l l i S C P O l l l b ElGlIlb G h t P M b Ac:.aI,r 'Energy' Specrlica!,an Cr-iscde! Frequency E :i;\albe Slnbillty (All S:a!er) S l a t l l l l y marglnr B'dCjliS Baabwlv r t n m e Delay B W O 7 c aandvr~dlh b ~ ~ m e el& O r ( G 3 . t ~ Ou~ckness (Pilch) All Other h ' i E s N C E ~ l I D ~ v l d e d (Pt.R) All C!her MTEs ( Y z ~ fill Other MTEr All Ot7er MTES 4 0 Z Z 4 : 1 0 20 3 i 0 20 4 0 60 El1dwld:n [radliec] 9 3 ? f i i l f h [radisec] (3:he!a)m1n [degl (dphornin [deg] TJr..:l5lib Oulciiless (Yaw) C0'311b COupilng C O P 3 ' 3 Coupling i O P 2 i : b Cokpllng PI1 @the' hlTEs P1::n/Pc:! or R o l W ~ l c h =,:cY=oll or RolliPi:ch v a w / C o l l e c l ~ v e b WGS1113 *GS111b '4 r d Gus! W.nd Gust Figurs 13 Handling quality anal>.sis of Bosing's control l a ~ v s Figure 15 Supporting plots for roll quickness handling quality specification. The input signal is negative because in this direction the aircraft exhibits a poorer response.
G ~ = I 2.45 d ~ , (w= 1 5.58) Pm=88.21 deg. (w=4.01 1 ) I 20 I
m
-a - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
r 0 - - ib / I . . ' . ' I I -20 1 02 1 0-' prequency I 0 I ~ r , -90 -
7-
n . . . . . . . . . . . . . . . .
- V) 0 -1 80 rd - - -270 I I -360 1 0-' 1 Prequency Sht Feb 22 2 0 : 0 3 : i 9 PSI 1997 Figure 16 The broken loop frequency response for the roll channel for the Boeing solution.
actuator energy. After rumling CONDUIT for 44 iterations a solution was reached.
Figure 17 depicts this solution. CONDUIT was able to satisfy all the handling quality requirements and drive down the crossover frequency. The design parameters for the The increase in the model design parameters initial and final case are given in Table 1.
allowed the cpntrol system to meet all the handling quality specifications. The most noticeable increase is in the roll and yaw model design parameters (Mphi and Mpsi) so the quickness and bandwidth specifications could be met.
Design Lnitial Final Design Initial Final Parameters Parameters 2.470 2 Mtheta 12.065 Ktheta 13.6 4.600 2.5 Mphi 8.488 Kphi 8 4.134 2 Mpsi 8.348 Kpsi 7.6 1 .OOO 0 KItheta 6.418 6.4 K q 2.328 0 KIphi .2809 2.4 K P 1.088 0 KIpsi 3.068 Kr 3.2 Table 1. The design parameters taken from Tischler (Ref. 9) paper and CONDUIT solution.
Figure 18 shows the supporting plot for the yaw bandwidth specification. The increase in the model parameter has shifted the phase curve causing the crossing of -135 degrees at 3 rad/s. The roll quickness has also improved due to the increase in the model design parameter. Figure 19 shows the supporting plots that justify this response. Also it can be noticed that the angle and rate responses are clean and don't possess any unwanted oscillations. The last item to notice is the reduction in phase margin in the roll channel attributed to a large decrease in Kp with the increase of KIphi. The significant reduction E l G l lhb q ? n i a l J e Stability (All Stales) U -'J O K U A I , ~ Q u ~ c k n e ~ s (RoIO Q K O ~ I I S Ou~ckness (Pitch) a H ~ : , , ~ 3 w N t d t h 6 n m e Delab All Other MTES AII Other MTES n l l Other MTES (Yaw) Figure 17 Figure 1 8 Yaw bandwidth supporting plots.
Figure 19 I The supponing plots for the roll quickness specification for small input signal once it has achieved Level 1.
Gm=l1.74 dB, (w= 8.283) Pm=52.28 deg. (w=2.89)
Gm=l1.74 dB, (w= 8.283) Pm=52.28 deg. (w=2.89) 50 I I m U - . . . . . . . . . . . . . . . . . . . . . . . .
c 0 - - rd
a
>, I I -50
I d1 1 frequency (rad/se$ 1 o2
0 I I - - r ~ , -90 7 s 0 -1 80 . . . . - V ) c rrl - -
E -270
I I -360
1 o2
1 0-' 1 1 y '
prequsncy (radisec Sun R b 2 3 1 5 : i 7 : 5 3 P 5 T 1997 Figure 20 Roll channel gain and phase margin supporting plot after tuning in CONDUIT envirom~ent.
' in crossover frequency in the roll channel can certainly be tied into the reduction of the phase margin. The supporting plot for the roll channel gain and phase margin in figure 20 can be compared to the previous case (figure 16). The reduction in Kp has had this effect in the design.
With the CONDUIT system a single engineer has tuned the control laws to meet I ADS-33 handling quality specs and reduced the crossover frequency to provide a better design. CONDUIT has produced a design that allows the single engineer to see the handling qualities as well as the frequency and time response data. The design could be completed in a day once a given architecture and list of specifications have been chosen.
The engineer can either alter the design parameters by hand or allow the optimization engine drive a solution that will end on the design margin.
5.3 hlodel Following Design for RASCAL The model following design used by RASCAL uses a second order model that represents desired aircraft performance that is believed to meet the specifications. The use of high gains in the feedback loops is to retnove any discrepancies between the actual dynanlics and the inverse approximation of the dynamics. Still in this method there is no expedient way for checking the model against a set of handling quality specs.
The idea behind model following is to implement a model that will represent the desired system dynamics and have the existing system be canceled out by an approximation of the inverse of the present system. The goal of this solution is to achieve a set of gains that would allow the control system to behave like the model and have the existing plant be canceled out. The handling qualities that me,asure the end-to- end response aren't the focus of this solution, but rather the ability to track a given model.
The purpose of this solution is to demonstrate that a model can b e implemented and the system dynamics can be effectively canceled out by producing an inverse approximation of the system and allowing feedback to compensate for the discrepancies.
The job of CONDUIT is to find a set of gains that allows the end-to-end response to closely m a t ~ h the model's response. With the system essentially reducing to M, a model of the desired performance can be placed in the system. Referring to figure 10; equation 11 shows that if P-1 is exactly equal to the inverse of the aircraft dynamics then the resulting system will be the model (M). The gains in the H block help minimize the difference between P and P-1.
R.T[P-~+H] [ P / ~ + P H ] Eqn 1 1 Perfect model following cannot be achieved in reality because the high frequency dynamics cannot be fully inverted in P-l. The high frequency dynamics can be approximated by an equivalent time delay, T. To maintain good model following, this equivalent delay must be added to the feed forward loop (Table 2). However this penalized the roll channel too severely, thus the delay is left from the roll channel so it behaves as lead (Ref. 4). Also matching the end-to-end response of the aircraft with the model is impossible since the highest feedback gains still won't get the high frequency phase curves to match. The best that can hoped for is to match t6e model time the plant delay M*D.
C h a n n e l Filter (ms) Actuator (ms) Helicopter Dynamics (ms) Total Delay (ms) , , 25 20 29.7 -75 Pitch Roll 25 20 26.8 -75 2 5 20 22.8 -75 Yaw Table 2. Delay parameters The model used for the model block was taken from Tischler's paper (Ref. 9). It is their model (equations 12, equations 13, and equations 14) being implemented in this design.
Eqn. 12 Eqn. 13 Eqn. 14 This model is not guaranteed to satisfy ADS-33 handling quality requirements.
The purpose of this problem is to utilize CONDUIT to track the model, and optimize for handling qualities. To prevent the optimization phase from trying to drive the model, these design parameters were frozen at the values that Boeing provided (Ref. 9). The bandwidth and quickness specifications were turned to check only since there could be no improvement with the fixed model.
In order to enforce model following a model following specification was created.
It is basedan a cost function that measures the mismatch between the two curves. To measure the degree of model following mismatch between the two frequency curves the parameter cost function was utilized. The cost function is defined in equation 15 (Ref. 5).
Eqn. 15 Where N is the number of data points being used.
The idea of the model follo~ving specification is to have the ability to see the difference between the two curves and show the contribution to the cost of the gain curve The cost and the phase curve separately. The model following is shown in figure 21.
due to mismatch in the gain curve is the value that come from the first half of equation 15.
This value is plotted on the vertical axis of the specification. The mismatch of the phase curves is calculated by second half of the cost function. This value is plotted on the horizontal axis. These two values added together equal the total cost. The spec works by limiting the total cost. Equation 16 has the cost equal the x plus the y values.
Restrict the model following to a single cost then solving for y you produce the limiting splines on the model following spec.
C o s t = y + x E q n s . 1 6 & 1 7 , y = Cost - x F1gul-e 2 1 The n1r.dt.1 fi.llo\\ing specification.
Figure 32.
Model follo~ving specification for the Bosing design parameters.
The requirements to be met are the overall stability, the gain and phase margins, the off-axis coupling, and the wind gust response. The program was setup to optimize for the cost function of the model and end-to-end mismatch, the actuator energy, and the crossover frequency. The initial case was the same as the initial case insection 5.2 (figure 13). The model following result for this case is seen in f gure 22. The yaw channel has good model tracking where the other two cases have significantly less. Although the tracking at the cost functions is relatively good it would not be ideal if the model following exercise was to act as a simulator for another aircraft model. Figures 23,24, and 25 show the mismatch between the model and end-to-end response. It became obvious that integral feedback loops would be needed to be closed around the system to ensure a high level of model following. These gains were initially set to 1. The optimization tuned them to a higher value eliminating the mismatch between the plant and inverse plant.
Final
1 Design Initial Final Design Initial
I
Para~ne ters Parameters 2 2 Mtheta 11.580 Ktheta 13.6 2.5 2.5 Mphi 5.513 Kphi 8 2 2 M p s i 6.613 Kpsi 7.6 9.032 0 KItheta 7.674 6.4 Kq 8.977 0 KIphi 1.361 2.4 K P 1.61027 0 KIpsi 1.661 3.2 Kr Table 3.
Initial design parameters as provided by Tischler's paper (Ref. 9) with CONDUIT optimized parameters for the model following solution.
Figure 23.
Supporting plot for the model follo\ving spec (pitch).
Input2 to Ouput2: (red dashed) Model: (green solid) I . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
n . . . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . . . .
m . . . . . . .
. . . . . . .
. . . . . . .
.............
. . . . . . . . . . . ......... ., I . . . . . . . . .I.. ...- ;IL,
--
. . . . . .
Q) . . . . . . .
. . . . . . .
a . . . . . . .
. . . . . . .
. . . . . . .
-t- - - . . . . . .
. . . . . .
C .....................
- . . . . . . . . . . ;. . . . . . .:. ....... . . . . . . .
. . . . . .
m-20 . . . . . . .
. . . . . . .
. . . . . . .
8 . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . . . . .
. . . . . .
- 4 0
1 0-' 1 o0 1 0'
Fr ke r d/ ec = 5
GOST = 31 : Average d e Y t i d X Y 6 7 ; 8ve/age deltaPHASE , b
I I I . . . . . . .
O L . . . . . . .
--
. . . . . .
. . . . . . . . . . . . .
- - - : - L
. . . . . . . . . . . . . . .
- ---. --
. . . . . .
: - - -?'-+...
. . . . . . .
. . . . . . _ . .
m . . . . . . .LC-<\ . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
a , . . . . . . . . . . . . . .
! . . . . . .
. . . . . . . . . . . .
_ . . . . . . - - + . . . . . . . .
P.
.............................................:......................... . . . . . . . . . . . . . . . .
- ;. . . . . . . ...- . . . . . . .
a , - 1 00 . . . . . . .
LO . . . . . . . I \ ; : : : : : . . . . .
. . . . . . .
. . . . . . . : ' -. ' . . '
K 3 . . . . . . . , . , .
r . . . . . . .
: : > \ , , ; ; 1 . . . . . . . . .
a . . . . . . .
. . . . . . . : : :\> : . . . . . . .
. . . . .
. . . . . . .
. . .
. . . . . . . . . . . . . . . . : \ - . . . . . .
-200
10-I 1 o0 1 o1
Frequency [radisec] Figure 24.
Supporting plot for the model following spec (roll).
Figure 25.
Supporting plot for the model following spec (yaw).
The result was a match of the end-to-end response to the model with costs of 12, 11 and 7 for pitch roll and yaw respectively (Figure 26). This is considered an excellent match as can be seen by the supporting bode plots in Figures 27, 28, and 29. Little change occurred in the bandwidth and quickness spec since the model is essentially the same as the end-to-end although the end-to-end response has changed slightly since it tracks the model closer. A new model is required to satisfy the quickness and bandwidth specifications. We see that the bandwidth on the yaw channel falls below the requirements for quickness and fails on the roll and yaw channel. The bandwidth is the result of the model for the yaw channel. Since such good agreement has been demonstrated between the model and the end-to-end response it seems that a better model would satisfy these requirements. The design parameters show the integrator gain in the pitch and roll channels to be much higher to compensate for the model following spec. As a result the phase margins are compro~nised and the wind gust show more overshoot than the ADS-33 solution. The model following solution showed that the crossover frequencies were forced even lower. The limiting factor for the crossover frequencies in this optimized design seemed to be the wind gust response. With the high integrator gain in the pitch and roll the crossover frequency could be reduced in these channels without driving the wind gust spec to the edge. The yaw crossover frequency is driven down as well. This occurred because when optimizing CONSOL-OPTCAD works only on the 'worst' specification data point. Since the roll crossover frequency was allowed to be reduced this allowed the optimization engine to reduce the yaw crossover frequency.
This explains why in this case the optimization was able to drive the yaw to the lowest allowable phase margin and this didn't occur in the ADS-33 solution.
E I G l llb C ? S i l l b A E h l l l b Etgenvalue S l a 3 l i t y (All Stales) c . : ; i ~ ' . e r Frequency S i : u l ! ~ r "Energy' Spec~ncallon 0 1 2 - 3 4 5 - 6 7 0 9 1 0 Total Ac1ua:ar Energy, [Nomal1red-R3la E ' i 0 7 1 1 3 5 ~ , , 3 ~ 1 a n d Tlme D e l a y 8'#C5\ 3 B a n d w l h 8. T ~ m e D e l a y A Z1:;er MTEr (Ya*) All O l i e : M T E s N C E > l / D l v l d e d (PLP,j 2 4 ear~t?adtn [rad/sec] 2 * J 5 1 b OulckrleSS (Ya*.)
AII O t h e r M T E r 3 2 20 4 0 60 l ~ n e [ L E C ] @ ~ a F r ~ ) m l n [degl WGS: i t > W G S l I l b wlr3 G ~ s l Wind Gus1 C O X D U I T ' s op~iolized parameters for ihe model follo\ving solution Model F o l l o ~ v i n g ADS-33 2.07 Crossover frequency Pitch 2.19 Z 2.05 2.89 Roll 2.07 Yaw 2.89 0.178 Actuator energy Pitch 0.285 0.089 Roll 0.283 0.063 Yaw 0.197 .
+ Table 4. The final values of the optimization constraints.
The mismatch of the phase curves as discussed in the Tischler's paper (Ref. 9) which was attributed to the improper use of delay in the feedfonvard system of the block diagram was shown to be corrected when the time delay was implemented.
This solution shows much lower crossover frequencies and these seem to be limited by the wind gust response. The actuator energy, previously thought to be a good reduction parameter was traded for crossover frequencies. Looking at the actuator responses for the several sets of design parameters shows that the actuator specification might not be smooth enough for optirnization. The spec might need to be used as check only or have the sensitivity reduced in the optimization algorithm.
The solution was able to meet all the feedback loop specifications while driving the crossover down and the phase margin to the boundary for all three channels.
Figure 27 Supporting plot for the model following spec with optilnized solution (pitch).
Figure 28.
Supportins plot for the model follo\ving spec with optimized solution (roll).
Model: (green solid) Input3 to Ouput3: (red dashed)
1 0-' 1 o0 1 0 '
GOST = 7 : Average d l e ' ~ # % h ~ = % ~ A " ~ $ a ~ e deltaPHASE = 3 A Figure 29 Supporting plot for the model follo~xing spec with optimized solution (yaw).
5.3 Windgust Rejection This problem will be used to demonstrate the trade-off possibilities that can be conducted by an engineer using CONDUIT. CONDUIT provides the engineer the ability of to compare families of designs which can provide insight into the relationship of competing specifications. This problem was also used as an example of a simpler problem that could be used as a demonstration problem that would run quickly and still have a co~nplex real world application. The problem statement was to design a controller that would allow the UH-60A Blackhawk helicopter to maintain it's position within a series of 10, 20, and 30 foot diameter circles while under the effect of turbulent wind for 100 seconds.
The feedback architecture consists of simple loops on the position and speed channels as seen in figure 30. The x, y, and z position vectors are calculated by feeding the integrated speed vectors u, v, and w. The position and speed are then fed back in to the pitch, roll, and collective inputs. For the small angles feeding angles into position is sufficient. The feedback gains are denoted as dp-Kx, dp-Ky and dp-Kz for the position and dp - Ku, dp - Kv and dp - Kw. For the body axis of the helicopter u and w are in opposite directions to the pitch and collective inputs this results in negative gains for the dp - Kx, dp-Ku, dp-Kw and dp-Kz gains.
Turbulence excitation was simply by adding noise into the pitch, roll and yaw channels directly before the aircraft dynamics. The wind model being used is placed into the B matrix of the 14 state space model pitch, roll and yaw channels directly.
I Figure 30 I Position and velocity feedback loops for position hold example. Includes sensor noise and turbulence models.
Measurement noise was added to the feedback loops in order to simulate sensor error. This became crucial since actuator energy is driven up as crossover frequency increases allowing higher frequency noise to affect the actuators.
The actuator energy spec is the same one that is used in the previous examples. It is determined as the square of the actuator rate normalized to the maximum rate summed over time. However a new spec that would maintain the helicopter within the boundaries of the circle needed to be created. This specification is shown in Figure 3 1. It consists of two axis and a curve spline. The quarter circle radius contains the boundaries for the helicopter's RMS radius during the gust to that point. The RMS radius is used over maximurn radius because it is more continuous. The spec was set up in this case with the yellow triangle representing the x position of the helicopter along the horizontal axis and the y position of the helicopter along the vertical axis. The y position and the z position are represented by the inverted green triangle. That gives the radius of the circle. The axis used were x and y position of the helicopter for the first point and y and z position of the helicopter for the second point.
The trade-off that would be demonstrated was actuator energy versus the RMS of the position within the series of three circles. The specs used in this example are crossover frequency, gain and phase margin, actuator energy and position hold. No design margin was used since the wind gust was an approximation and not based on a reliable wind models, this being a demonstration model the design would have no real meaning other than forcing our design to be within slightly smaller circles.
For deciding on initial gains classical methods were us$d once the broken loop frequency responses were taken and then the location of 45 degrees of phase margin was PHDl lib: Positiorl Hold Specification 0 1 0 20 30 RMS Fosition Deviation [ft] Figure 3 1 The position hold specification.
read along with the required crossover frequency. Gains were found in order to drop the frequency response to the required crossover frequency.
The optimization scheme was set up to drive the RMS position within # the radius of the three curves. The initial solution has the RMS value of the on the Level I curve of a 10 ft radius (Figure 32). This is considered the solution for the minimum RMS value. The actuator energy is the highest in the roll channel indicating that the wind has the most effect on the helicopter in the rolling and lateral directions. This is supported since the moment of inertia is the least in this axis. The supporting plot to the position hold specification is a time history of the helicopter's x and y position (Figure 33). Although the helicopter moves outside the 10 ft circle the RMS value is within the 10 ft. circle. The trade-off of holding the helicopter in a small circle is the actuator energy.
Since the roll energy was so high this will be looked at in comparison with RMS position.
Figure 34 shows the supporting plots for the actuator. The actuator rate is used to deternine the energy used. The actuator rate is the bottom left graph in figure 34. The maximum rate for this actuator is 10 idsec. The figure shows us that the actuator saturates frequently during the simulation hitting values of 10 several times. CONDUIT will try and drive the actuator energy down for the roll channel down with the expected result of a larger RMS value for the position of the helicopter.
The position hold specification was relaxed to allow greater movement as shown in figure 35. Figure 36 shows the actuator energy after CONDUIT has driven it down.
The RMS value now lies at about the 14 ft radius. The time history of the helicopter shows the increase in movement in the y direction (figure 37). This incjease in RMS value has allowed the actuator rate to reduce to a maximum value of 8.5 inlsec. The trade P H D l l l b .
E l G l Ihb C R O l Ilb Pasr:ion H o l d SpecMcatlon Crossover Frequency Elgenvalue Stablllly (All Stales) , ,. . . .
P H D l I l b . A E N l Ilb A E N l Ilb.
Position Hold S p e c M c a l ~ o n Actuator 'Energy' Specificalion Aclualor 'Energy' Specificallon Actualor 'Energy' Specification Figure 37 Windgust solution for minimized RMS position.
Position From Trim(yellow) RMS Posilion(green ") Figure 33.
Time history plot of the helicopter's position for minimized RMS position.
, 6[Normalized~Pos1t1on^Z/sec^Z)j(Maximum " E n e r g y N = l Minimum ' Maximum Rate.10 I Minimum m a - " E m e r g y " = l Figure 33 Supporting plot for actuator energy (roll) with saturation in the actuator rate.
C R O l Ilb- ElGlIlb PHDl lib Crossover Frequency E i g ~ n v a l u e StaS~llty (All Sta:er) Posdion Hold Speclficallon . .
A i N l I l b A E N l lib A E N l I l b P o r H ~ o n Hold Speclflca!~on Aclualor 'Energy' Specificclan Actuator 'Energy' SpeclllcaI~on Artualor -Energys Spec~flcnlon Figure 35 blcdium R\IS position hold solution.
Figure 36 Time history plot of the helicopter's position for medium RMS position.
Input Signal Figure 37 Supporting plot for actuator energy (roll) with saturation in the actuator rate.
off is becoming obvious, actuator energy for position hold. After reducing the actuator energy further (figure 38) the RMS value of the helicopter's position is near 27 ft. The supporting plot shows the helicopter approaching 60 ft in the y direction (figure 39).
The actuator rates again decreased as seen in figure 40 to a level of 5.9 idsec. The complimentary nature between the actuator energy and the crossover frequency can be noticed as they both decreased during the optimizations. The lower crossover frequency acts as a filter screening out higher frequencies of sensor noise which drive the actuators excessively.
The large difference between the RMS value and the maximum value, seen in the last case, will need to be investigated in order to determine an algorithm that might properly contain the helicopter within a specified radius. However, for the purpose of this example the correct trade-off has been de~nonstrated to show the trade-off between the actuator energy (and rate) and the position held by the helicopter (Figure 41). These trade-offs allow the engineer the ability to make decisions about actuator performance for required tasks. Engineers have the option to investigate whether or not the most costly, faster actuator is required without having to rework the control system parameters.
CROlIlb ElGt Ihb P H D l Ihb Crossover Frequency Elgenvalue Slabttny (All Slates) Posltton Hold Specifitalton . .
AENlitb A E N ~ I I ~ : AENlItb- Poiillon Hold Spec~dcat~on Actualor 'Energy' Specilicalton Actuator 'Energy' Spec~ncal~on Actuator 'Energy' Specification Figure 38 Large RhIS position (minimized roll actuator energy) Position From Trim(yellow) RMS Posi ti on(green ") -- 30 E E
- , 20
E
2 10
L L -0 0 i- . - LO
a -1 0
-20 -30 -40
-20 -1 0 0 20 30
11O Position From rim [ft]
Figure 39 Time history plot of the helicopter's position for large RMS position.
M m i m u m Position=0.3779 I Minimum Position=-2.285 Input Signal 0 . 5 0 8 0.6 . . . . . . . . . . . ; ................................... ;..........
- 1 I -2.5 0 20 10 60 80 100 0 1 2 3 t 5 lime ysca rime h a Maximum Rate-5 639 1 M i n i m u r i f Q a t d ' ~ ~ = O . 3 4 -10 0 2 3 4 5 0 1 2 3 4 5 rime b e a Time C e a Figure 40 Supporting plot for actuator energy (roll) with saturation in the actuator rate.
Actuator Energy vs. RMS helicopter position 1.8 1.6 1.4 1.2 0.8 0.6 0.4 0.2 0 5 10 15 2 0 25 30 RMS position (y direction ft.)
Figure 4 1 The trade-off between hover hold and actuator energy.
Chapter 6.0
Chapter 6.0
Lessons Learned During This Thesis
6.1 Additional information learned during the thesis During the course of my research grant at NASA Ames I was able to participate in the development of a real world application and actual helicopter control system design.
Before coming to work at A ~ n e s I had no experience with helicopters. The opportunity at Ames educated me to the basics of helicopters and how they are a unique and amazing aircraft with properties not found in fixed-wing vehicles. I was able to develop skills in classical control design as well as, optimization, handling qualities analysis especially for rotorcraft. I learned project development skills working with team members at Ames, the University of Maryland, and Cal Poly.
Chapter 7.0
Chapter 7.0
Conclusions
7.1 Conclusions The development of CONDUIT has produced a powerful tool for control system design and analysis. It provides an interface that allows for the design of control systems that satisfy handling qualities. CONDUIT calculates a set of specifications, that typically took weeks, within a few minutes. This power allows for a more detailed analysis of control systems and allows the user to experiment with different controllers within a short period of time. It succeeded in being flexible to use any control architecture that the engineer desired. This power and flexibility placed into a GUI environment that allows for simple and rapid setup procedures combined with detailed analysis that provides the user with information that supports the results all with simple mouse commands.
The three examples demonstrated the power of CONDUIT as well as illustrating the point that this is a tool for the engineer with the knowledge of control system design to work it properly. The design problems showed how quickly it could be demonstrated that the controller wouldn't meet the specifications. It showed how tuning the design could find a solution that could meet the handling quality specifications.
Like any new program or tool there are limitations to CONDUIT. Several specs have been encountered that aren't based on a continuous function and stall the system when trying to opti~nize against these specs. Although they can be evaluated in CONDUIT a substitute specification will be needed to be used to enforce the other specification during tuning. Another limit to the optilnization process is the minimization of objectives is limited to the largest value of any of the objective functions. The one area that isn't so easy to use is creating new specs. Although they are written in a straightforward manner a knowledge of MATLAB is required. Work is being done on make new design simpler.
7.2 Discussion of Future Work Currently work is being done on CONDUIT to incorporate LOES Lower Order Equivalent Systems specifications. These are a popular subset of fixed wing specifications that fit a lower order model to a high order frequency response curve from which dynamic properties can be determined. Work on this is being perfonned by Mark Morel, another Cal Poly graduate student. Mark is currently working on a control system design for the X-29 as a part of his master's thesis. Demonstrations of CONDUIT to industry have created a lot of interest in the program.
Future work will focus on improving the optimization package, developing tools that allow the user to develop new specs in a easy-to-use environment. Plans are to integrate CONDUIT into a design cycle that will allow the designs produced on CONDUIT to be integrated into simulation environments and actual aircraft controllers with limited conversion and reprogramming of the control system design.
< More rigorous testing of the ADS control laws needs to be performed before the model following control system arrives this fall for the RASCAL helicopter.
References
6) Aiken, E., Jacobsen, R., Eshow, M., Hindson, W., and Doane, D., "Preliminary Design Features of the RASCAL--A NASNArmy Rotorcraft In-Flight Simulator," AIAA-92-4 175, I Aug 1992.
2) Fan, M. K. H., Tits, A. L., Zhou, J. L., \ITang L. S., and Koninckx, J., "CONSOL OPTCAD, User's Manual. Technical Report 87-212r2a, Department of Electrical Engineering and Institute for Systems Research, University of Maryland, College Park, MD, 199 1.
7) Fletcher, J. W., "Identification of UH-60 Stability Derivative Models in Hover from Flight Test Data," J. American Helicopter Society, vol. 40, no. 1, 1995, pp. 32-46.
10) Glusman, S. I., Conover, H. W., and Black, T. M., "Advanced Digital Optical Control System (ADOCS) Volume I11 - Handling Qualities." USAAVSCOM TR 90-D-1 lC, Nov 1990.
11) Hoh, R. H., Mitchell, D. G., Ashkenas, I. L., Klein, R. H., Heffley, R. K., and Hodgkinson, J., "Proposed MIL Standard and Handbook -- Flying Qualities of Air Vehicles, Vol. 11: Proposed MIL Handbook," AFWAL-TR-82 - 308 1, 1982.
, 1) MATLAB@: High-Performance Numeric Computation and Visualization Software. The Math Works, Inc., Reference Guide, 1992.
8) Takahashi, M. D., " Flight Control Design Using Rotor-State Feedback for an Articulated Rotor Helicopter in Hover. NASA Technical Memorandum 103967, Jan 1993.
5) Tischler, B. Mark., Advances in Aircraft Flight Control, Taylor & Francis Ltd., Bristol, PA, 1996.
9) Tischler, M. B., "System Identification Requirements for High-Bandwidth Rotorcraft Flight Control System Design", J. Guid., Control., and Dyn., vol. 13, no. 5, 1990, pp. 835-841.
4) United States Department of Defense, "Flying Qualities of Piloted Vehicles", MIL-STD- 1797, March 1987.
3) United States Army Aviation Systems Command, "Handling Qualities Requirements for Military Rotorcraft", ADS-33C, ST. Louis, MO., August, 1989.