Modeling, Simulation and Rapid Prototyping of an Unmanned Mini ...

5 downloads 622 Views 1MB Size Report
The main module in the environment is the mini-helicopter simulation model. .... The mini-helicopter is equipped with a wireless bridge and one or more laptop.
AIAA 2006-6737

AIAA Modeling and Simulation Technologies Conference and Exhibit 21 - 24 August 2006, Keystone, Colorado

Modeling, Simulation and Rapid Prototyping of an Unmanned Mini-Helicopter Carlos Mario Vélez* and Andres Agudelo† EAFIT University, Medellin, Antioquia, Colombia and Jorge Alvarez‡ University of Texas, Austin, Texas, 78712 This paper presents a rapid software prototyping environment (RSPE) for the design, simulation, and real-time implementation of a control system for an autonomous minihelicopter. The software prototyping environment consists of diverse modules, including a mini-helicopter simulation model, a navigation filter, different controllers, a ground control station, and linearization and parameter identification tools. The environment is intended to reduce development time and costs, giving the designer more time to focus on mathematical and algorithmic methods. A hardware-in-the-loop (HIL) simulation example is presented to study the use and advantages of the prototyping environment in control design and simulation.

Nomenclature δcol δlon, δlat δr δt u, v, w p, q, r φ, θ, ψ x, y, z a1, b1 Ω m, I X, Y, Z L, M, N uw, vw, ww λ,µ,A,B,τe R, kµ, a, σ

T

= = = = = = = = = = = = = = = =

main rotor collective control input longitudinal and lateral cyclic control inputs tail rotor collective control input throttle control input vehicle velocities in body axes vehicle angular rates in body axes Euler angles (roll, pitch, yaw) vehicle position in navigation axes longitudinal and lateral main rotor flapping angles main rotor angular speed vehicle mass and inertial tensor external forces acting at the vehicle center of gravity external moments wind velocities in body axes main rotor variables main rotor parameters

I. Introduction

HIS paper presents the design, simulation, and real-time implementation of a control system for an autonomous mini-helicopter using rapid software prototyping tools. These tools include a mini-helicopter simulation model, a navigation filter, several controllers, a model linearization tool, and parameter and heuristic identification functions. The rapid software prototyping environment (RSPE) is intended to reduce developing time and cost, giving the designer more time to focus on mathematical and algorithmic methods. *

Associate Professor, Basic Sciences Department, [email protected]. Research Assistant, Basic Sciences Department, [email protected]. ‡ Teaching Assistant, Aerospace Engineering and Engineering Mechanics Dept., [email protected], AIAA Student Member. †

1 American Institute of Aeronautics and Astronautics Copyright © 2006 by EAFIT University. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

Every module in the software environment was developed with Matlab/Simulink1, allowing rapid prototyping with automatic code generation for real-time operating systems as QNX. Extensibility is granted since any available Matlab toolbox can be used to improve it (e.g., signal processing, artificial neural networks, optimization, etc). This approach is particularly useful for education and research, due to a well documented object-oriented structure which facilitates its use by students and researchers. It is possible to implement, simulate, compile and test in real time any control system for the mini-helicopter in a fast and intuitive manner. The main module in the environment is the mini-helicopter simulation model. This model is a state-of-the-art synthesis of well-known models and it is implemented entirely in Simulink blocks. The model has a structure that allows real-time code generation and software-in-the-loop simulation (SIL); it was validated by an expert acrobatic pilot in real-time SIL tests, demonstrating that the control reacts faithfully to pilot commands. A ground control station interface, with a set of gauges and a mini-helicopter virtual reality 3D model, facilitates this type of test. To date, PID, fuzzy, state feedback, and multirate control systems have been designed and tested. In the multirate case, several control sampling patterns have been studied, allowing measurement at different sampling rates and control design under sampling considerations. Model identification is done with the Matlab “Parameter Estimation Toolbox” together with the mini-helicopter simulation model. An interesting result is the possibility to use a complex model as a model structure and estimate unknown or inexact parameters, obtaining a better simulation model and computing proper linear models directly from it. The RSPE presented in this work combines several tools that are significant for modeling, design, simulation, and control of UAVs, an area of intense development in aeronautics research2. It differs from other similar environments where Matlab is used without taking advantage of its full potential. For example, the software described in Ref. 3 focuses on real-time and scheduling problems, employing Matlab only for the control task. It is not specified how the environment speeds up tasks such as identification control, state estimation, and visualization. MoSART (“Modeling, Simulation, Animation, and Real-Time Control”), described in Ref. 4 and Ref. 5, is an interactive Matlabbased environment which is used for analyzing, designing, visualizing, and evaluating the performance of aircraft control systems. The environment lacks state estimation and identification modules, and processoriented tools such as code generation for real-time operating system. MultiUAV2 described in Ref. Figure 1. Software prototyping environment modules. 6 is an environment based on Matlab for cooperative flight, but mostly uses script functions programmed in C++ and it is limited to simulation. It has been used for developing and testing cooperative control algorithms, implementing time-optimal trajectories. In Ref. 7, a prototype simulation and 3D visualization tool for cooperating UAVs, working semi-autonomously or manually, is described. It has useful functions and prototyping capabilities, but it is mainly oriented towards simulation and visualization. Commercial aerospace applications based on Matlab are given in Ref. 8 and Ref. 9. These examples show the power of this type of prototyping environment. The remainder of the paper is organized as follows. Section II presents the main characteristics of the proposed RSPE. Section III introduces the key ideas of mini-helicopter modeling, explained in detail in Ref. 10 and Ref. 11. Section IV describes the main modules of the RSPE. An HIL application of previously described modules is given in Section V. Concluding remarks and ideas for future work are provided in Section VI.

II. Description of the rapid software prototyping environment Rapid software prototyping is the process of automatic early development of a working version (prototype) of a system used to test out certain key features of a design, demonstrate concepts or methods, and to gather early user

2 American Institute of Aeronautics and Astronautics

feedback12, 13. An adequate RSPE must be useful for different tests, including SIL, HIL, and human-in-the-loop (HMIL) simulation. The RSPE presented in this paper (called “Colibri” from Spanish word for hummingbird) was built entirely using Simulink, a visual programming language that allows the simulation either in machine or real time, and consists of custom modules (X-Cell mini-helicopter nonlinear mathematical simulation model, digital filters, multirate control11, 14, 15, navigation filter with an extended Kalman filter) and modules based on Matlab tools (linearization, parameter identification, heuristic identification, fuzzy control, control ground station, etc). The modules and their interaction are shown in Fig. 1. A trajectory generator and a Finite State Machine for discrete events are being developed. Automatic code generation for several operating systems as QNX16 (called targets) and communication between ground control station and target computer, where the control software runs, can be accomplished in Simulink by means of Real-Time Workshop (RTW), a toolbox that allows the generation of standalone C code from a simulation diagram and the tuning and monitoring of parameters in execution time. Both a commercial17 and a custom18 target solution were used to generate and transfer code to the target computer. A normal session with the Colibri RSPE includes the following steps: 1) tuning of the simulation model for analysis, design and simulation; 2) separation of the controller, estimation, filter, transformations, and logical blocks from the plant model; 3) attachment of driver blocks; 4) automatic C code generation and conversion to real-time executable binaries; 5) loading onto target hardware; 6) connection to target; 7) monitoring of signals and tuning of control parameters using Simulink as a graphical user interface and 8) loading data for analysis. Input to the model during runtime is done with different user interface objects including special gauges (e.g. sliders), text boxes, and joystick controls (custom input) for HMIL tests. Although the RSPE contains a mini-helicopter model, any new vehicle model could be created and used. The target computer is a PC-based Figure 2. X-Cell 0.60 Gas Graphite helicopter with avionics box. system which can be a typical desktop computer or an embedded flight computer (i.e., PC-104 form factor). Standards as Ethernet, wireless 802.11b and UDP/IP and TCP/IP protocols, are used for both file transferring and monitoring. The mini-helicopter is equipped with a wireless bridge and one or more laptop computers can be used as ground or monitoring stations. A special communication module, available through the Simulink design interface, was developed to guaranty an updated view of the helicopter state during flights; the module takes model parameters and forwards them through network using UDP, which is a fast and efficient protocol for time-sensitive purposes.

III. Mini-helicopter model The mini-helicopter is a hobby helicopter (see Fig. 2). The inputs and states of the mini-helicopter system are given in Eqs. (1) and (2). The mini-helicopter is an eight-degree-of-freedom system: three velocities (u, v, w), three angular rates (p, q, r), and two main rotor flapping angles (a1, b1). u = [δ col

δ lon δ lat

δr

δt ]

T

(1)

x = [u , v, w, p, q, r , ϕ, θ, ψ, x, y, z , a1 , b1 , Ω ]

T

(2)

Main equations of motion are given by Eqs. (3) – (5), but other equations such as rotor dynamics, engine-drive train, and actuators dynamics are considered into simulation model. Higher-order effects (lateral and longitudinal

3 American Institute of Aeronautics and Astronautics

tip-path-plane flapping) are taken into account in Eq. (5) to improve the rigid-body model accuracy. The coupled rotor and stabilizer bar equations are lumped into one first-order equation of motion.

u = ( vr − wq ) − g sin θ + X / m v = ( pw − ru ) + g cos θ sin ϕ + Y / m w = ( qu − pv ) + g cos θ cos ϕ + Z / m p = qr ( I y − I z ) / I x + L / I x

(3)

q = pr ( I z − I x ) / I y + M / I y r = pq ( I x − I y ) / I z + N / I z ⎡ φ ⎤ ⎡1 tan θ sin φ tan θ cos φ ⎤ ⎡ p ⎤ ⎢⎥ ⎢ − sin φ ⎥⎥ ⎢⎢ q ⎥⎥ cos φ ⎢ θ ⎥ = ⎢0 ⎢ψ ⎥ ⎣  ⎦ ⎢⎣ 0 sin φ / cos θ cos φ / cos θ ⎥⎦ ⎢⎣ r ⎥⎦

Bδ b 1 ⎛ 4δ ⎞ v − vw + lat δlat b1 + 1 = − p + 2kµ ⎜ col − λ o ⎟ τe τe τe ⎝ 3 ⎠ Ω mr Rmr a 1 a1 + 1 = − q + τe τe

⎡ 16µ 2mr w − ww ⎤ Aδlon ⎛ 4δcol ⎞ u − uw sign µ mr − λo ⎟ + kµ δlon ⎢ 2 kµ ⎜ ⎥+ 8 µ mr + amr σ mr Ω mr Rmr ⎥⎦ τe ⎝ 3 ⎠ Ω mr Rmr ⎢⎣

(4)

(5)

IV. Modules of the Colibri RSPE The main modules of the Colibri RSPE are now described in more detail. A. Mini-helicopter simulation module The simulation model was coded in Simulink using only blocks (without functions or S-functions) and integrated in one Simulink file, so the real-time code generation is straightforward and may be used in SIL, HIL or HMIL simulations (see Section V). This characteristic was used for validation of logical model structure by an expert pilot, using a joystick and a 3D visual interface. The parameters of the minihelicopter model are defined in Ref. 10 and Ref. 11. Fig. 4 includes the front-end (mask) of model. B. Inertial navigation module It is not realistic to assume that all output vehicle variables can be measured. Even if it were possible, there are measurement errors and noise that could be minimized using data from different sensors (navigation aids), such as GPS, barometer, magnetometer, Figure 3. Implementation of EKF in Simulink. sonar, accelerometers and gyros19 (the last two are integrated into an Inertial Measurement Unit – IMU). An Extended Kalman Filter (EKF) is an optimal predictor-corrector estimator that uses the knowledge of kinematical models, measurement errors, sensor models, and initial condition information to estimate position, velocity and attitude of a vehicle. The estimated state is a combination of a predicted state and a correction using measurement data. An EKF was implemented in the environment using only Simulink blocks (Fig. 3), making it possible automatic code generation. 4 American Institute of Aeronautics and Astronautics

C. Control module Several control methods have been tested with the mini-helicopter simulation model. The first method is a PID (Proportional-Integral-Derivative) control with anti-windup and bump-less transfer considerations. This heuristic method is used to obtain control input values in different operational points (e.g., hover or cruise) and as an initial control which helps to compare other model-based methods. Inaccuracies in parameters and initial conditions are introduced. The PID controllers use position and velocity errors separately, which improve closed-loop behavior. Governor controller and wind gust are modeled. Other implemented controllers include fuzzy, state feedback and multirate. In Fig. 4, a multirate control, implemented using the Multirate Control Toolbox15, is applied to the minihelicopter. A single-rate state feedback control is obtained for a linearized model around a hover operating point (obtained with a PID controller), and then Figure 4. Multirate control. translated into a multirate control using the multirate modeling method discussed in Ref. 11. Linearization is performed using tools available with Matlab. D. Model linearization module Control design of a complex nonlinear mini-helicopter model is not a trivial problem. Usually, approximated models are used and the controller is tuned around a selected operational point. In the environment, linearization is readily accomplished using Matlab tools. The linearized model was also obtained theoretically from mathematical equations and compared with models from other references20, 21. This process helped in the validation of the simulation model and to estimate different model parameters from experimental data. E. Ground Control Station module The ground control station (GCS) was built completely with Figure 5. Ground control station (GCS) for supervision of an Matlab/Simulink blocks and may be autonomous mini-helicopter flight. configured according to specific tests. For example, the GCS is different for identification, experimental tests or supervision tasks. It is not a single module, but the integration of elements as gauges, a virtual reality model, time plots, maps, etc., as it is illustrated in Fig. 5. This is an interesting concept, because designers usually think of a ground station as a single program.

5 American Institute of Aeronautics and Astronautics

F. System identification module It is important in the flight control development process to use experimental data, in addition to HMIL simulation tests, in order to refine the simulation model and, at the same time, to obtain a more accurate and reliable mathematical model for the control design. Methods such as MOSCA and CIFER point in that direction20, 22, 23. The interaction between both models (theoretical and estimated) helps to identify system parameters, without using wind tunnels24, 25. The mini-helicopter simulation model allows the application of different parametric and heuristic identification methods, in open- and closed-loop. It is possible to estimate indirectly some parameters, comparing a good theoretical linear model with an experimental one, or directly with the simulation model, using closed-loop data with persistent excited reference signals and heuristic methods such as evolutionary computation and optimization, applying the Matlab “Parameter Estimation Toolbox”. Therefore, the nonlinear identified model and the simulation model are the same. This is a really interesting approach, because any indirect computation such as linearization20 is unnecessary. Moreover, it is important to take into account that closed-loop identification with parametric methods (least squares, prediction error, etc) is inexact due to negative effects of feedback, which generates a bias in the estimation.

V. Hardware-in-the-loop (HIL) simulation The main function of a RPSE is to test key design features and demonstrate concepts or methods12, 13. In the context of control design a RSPE must be useful for different tests such as HIL simulation. A HIL simulation provides a controlled environment to test individual modules and processing units. For example, applying the actual control software with a real-time helicopter simulation model helps the designer to find possible design errors and bottlenecks. HIL simulation validates both logical and physical components of the helicopter control system and shows the communication delays, making it a fundamental step before real flight tests. Key modules from the RSPE were used to build a HIL simulation environment, where different controllers and configurations could be tested. In the next subsections, initial software design, implementation, communications, avionics, HIL simulation, and results will be described. A. Initial software design The first step in HIL simulation was to build a SIL simulation environment that includes main software components. With SIL simulation the designer is able to track errors and tune simulation parameters previous to HIL simulation. Main process units and modules involved Figure 6. SIL simulation architecture. in simulation are presented in Fig. 6. Three major components are shown: a ground control station, a flight computer, and a helicopter model. Implementation and interaction of these three components can be seen in Fig 7. Every one of the dotted boxes represents an individual file containing various interconnected Simulink modules of the Colibri RSPE. Each one of these files represents one of the processing units displayed in Fig 6. Simulink models for the control and ground station in SIL simulation are the same as the ones to be used in real flight. Switch blocks were placed in the middle of signals, making possible to switch from SIL to real hardware with just a few clicks on the design environment before starting simulation. The same model which contains the control on real hardware will then be used in real flight or HIL simulation. B. Simulation modules The three individual files colibri_ground.mdl, colibri_air.mdl, and colibri_model.mdl were assembled with elements of the RSPE and basic Simulink blocks. The colibri_ground.mdl file is integrated by flight gauges, a virtual reality model, and command input boxes. This file is executed on a desktop or laptop computer which runs the Windows Operating System. The ground station can plot any of the state variables of the system in flight or simulation.

6 American Institute of Aeronautics and Astronautics

The colibri_air.mdl file integrates the control system, navigation filter, digital filters, and data acquisition drivers. This file is converted to C code, transferred to and executed in the mini-helicopter flight computer, being this the main software processing unit in real flight or HIL simulation. The switch block inside the driver’s logic, as shown in Fig. 7, toggles between software and hardware modes. The colibri_model.mdl file encapsulates the minihelicopter mathematical model. It represents the helicopter and its environment in both SIL and HIL simulation, differing only on the communication channels used in each case. This model runs in an individual desktop PC computer. C. Communication Network communication is necessary because each file runs in a different computer. Two blocks from the Figure 7. Simulink models interaction. RSPE (udp_tx and udp_rx) are used to transfer variables or array of variables from one simulation node to another. For example, the mini-helicopter velocities and positions have to be transferred from the model simulation computer to the flight computer. To connect two components, it is just a matter of importing an udp_tx (udp_rx) block into the design interface and redirecting the desired variables to the block input (output). For the mini-helicopter case, the designer takes this output and connects it to the modules to be fed (e.g., state variables directly feed the control module at the other end). Figure 8 shows the connections between the models in SIL simulation. The links between flight and model computer are replaced in real flight or HIL simulation with the corresponding device drivers. The round trip delay on this setting was measured to be 30 milliseconds on average, resulting in a delay of approximately 15 milliseconds from one module running on one Figure 8. Communication in Software-in-the-loop simulation. computer to another module on a second computer. Tests were done in a 100 mbps LAN. The simulation step time was of 10 milliseconds and had no considerable effect of delay. D. Avionics The actual flight configuration includes primarily a PC-104 flight computer, sensors, servo actuators and communication link (a serial RS323 channel and a Controller Area Network CAN). A schematic block diagram showing the overall architecture is depicted in Fig. 9. The devices are interconnected by the CAN bus, accessed from the flight computer with a RS232 bridge. The Inertial Measurement Unit is connected directly through an RS232 port to the flight computer. A CAN was chosen due to its extensibility and robustness, making it possible to add more sensors or actuators in an easy way. Most of the sensors and actuators are off-the-shelf components. The PC-104 is a DSP Design 300 MHz form factor computer. Sensors include a PNI TCM2 magnetometer-inclinometer, a Honeywell HPA Precision Barometer, a U-blox TIM-LF GPS and a Crossbow MNAV100CA inertial unit. Actuators are Futaba servos S9254 and S9252. Modules on the Colibri RSPE were built to work as drivers, taking sensor information and converting model control responses to servo actions. These modules are compatible with any of the modules on the RSPE and are not exclusive for the mini-helicopter devices.

7 American Institute of Aeronautics and Astronautics

Every module of the RSPE can use sensor information by including the sensor reading driver block on the design interface. Sample rates were measured to be approximately 30 Hz for magnetometer and inclinometer, 20 Hz for barometer, 5 Hz for GPS, and 100 Hz for inertial unit. Figure 10 shows in detail how avionics are interconnected and powered. These avionics are enclosed in a 30 cm × 18 cm × 10 cm avionics box. Figure 11 illustrates how the components are mounted in the mini-helicopter. E. Hardware-in-the loop set-up In the HIL set-up (See Fig. 12), the sensors, actuators and CAN bus are replaced by a PC running the minihelicopter simulation model. The same simulation models used for SIL and real flight are used, since the minihelicopter model reacts to the control as the real helicopter. Special Simulink blocks were created to convert model outputs to sensor-like outputs, imitating the sensor response. Messages are encoded in such a way that the flight computer cannot distinguish if the values are produced by sensor readings or by a model. The sensor readings are processed by the control algorithm on the Figure 9. Real world architecture. flight computer and a response signal is generated and sent from the flight computer to the servos through the actuator drivers. A Simulink block connected to the mini-helicopter model converts servo values and passes them to the mini-helicopter model, thus closing the control loop. F. Results Effectiveness of the RSPE in HIL simulation was evaluated in two fundamental aspects: validity of modules and design benefits (mainly time saving). Results from single-computer and HIL simulation were very similar and differe only in startup and convergence times. These differences were caused by delays in communication channels, which are not present in stand-alone computer simulation. In relation to design benefits, there are three important aspects. First, the Colibri RSPE separates model logic from design view, not being necessary for the designer to know specific module details. At the same time, this does not prevent the developer to further analyze modules and go deeper in details on every subsystem, if needed. Second, the same modules used for SIL simulation are easily extended to HIL simulation Figure 10. Mini-helicopter avionics. and real flight tests, reducing both design and implementation time – RSPE design view is the same for the prototype and the final system. Third, detecting and correcting errors is easily during simulation, saving debugging time and costs. For example, during simulation it was found that delays (delay on the RS232 channel and quantization errors) seriously affected tail control, but after some software changes flight control was attained in the HIL frame. These problems are difficult to detect in single computer simulation and may cause severe troubles in real flights.

8 American Institute of Aeronautics and Astronautics

VI. Conclusion The rapid software prototyping environment presented in this paper allows the analysis, design and rapid prototyping development of a real-time control for an X-Cell mini-helicopter. This is done in an intuitive and efficient way, with reduction of programming, debugging and understanding time by researchers and students. With the environment, it is possible to test new methods (control, monitoring, signal processing, estimation, identification, etc) in an easy and flexible manner. The environment integrates general tools based on Matlab toolboxes, with the possibility of adding new functions according to new requirements. Colibri RSPE has some advantages over other Figure 11. Avionics mounted in the mini-helicopter. prototyping environments: 1) it supports active participation in the design process through a block diagram modeling environment; 2) it accelerates the learning curve and simplifies the information exchange between different technical domains; 3) the prototype is equivalent to a specification document; 4) errors can be detected earlier, reducing costs and development time; 5) it increases creativity; 6) it speeds-up the development cycle due to the close interaction between programming and prototyping, giving more time to algorithmic and mathematic methods. On the implementation side, to date, successful tests have been performed with avionics and software in flight, without controlling the mini-helicopter. Real flight control is being prepared with the HIL platform. Significant results have been achieved with tests of vertical, longitudinal and lateral controls. Further work is required for tail rotor control as faster response is needed. Other tests are necessary to validate and exploit all possibilities of the software environment. Future work will be focused on discrete event modeling, system identification with heuristic methods, navigation filter Figure 12. HIL simulation architecture. optimization, control design, multirate control, flight tests, hardware improving, and application to other type of vehicle.

Acknowledgments This work is supported by Colciencias (Colombian Institute for Development of Science and Technology), project code 1216-14-14884. Authors thank EAFIT University, students of Mathematical Engineering of EAFIT University, Jairo Vergara from Medellin University, Nicolas Ariza from Industrial Aeronautica and the minihelicopter pilot Federico Hinestrosa by their constant support to the Colibri project.

References 1

Matlab, Software Package, Ver. 7.0, The Mathworks Inc., Natick, Massachusetts. Ollero, A., and Merino, L., “Control and perception techniques for aerial robotics”, Annual Reviews in Control, Vol. 28, 2004, pp. 167–178. 3 Henzinger, T.A., Kirsch, C.M., Sanvido, M.A.A., and Pree W., “From Control Models to Real-Time Code Using Giotto”, IEEE Control System Magazine, No.1, 2003, pp. 50-64 2

9 American Institute of Aeronautics and Astronautics

4 Rodriguez, A.A., Tae-Young, K., Chen-I, L., and Metzger, R.P.A, “A tool for analyzing, designing, and visualizing multivariable aircraft control systems”, Proceedings of American Control Conference, Vol. 1, 1999, pp. 237-241. 5 Rodríguez, A.A., Metzger, R.P., Cifdaloz, O., and Dhirasakdanon, T., “Description of a Modeling, Simulation, Animation, and Real-Time Control (MoSART) Environment for a Class of Electromechanical Systems”, IEEE Transactions on Education, Vol. 48, No. 3, 2005, pp. 359-374. 6 Rasmussen, S.J., Mitchell, J.W., Chandler, P.R., Schumacher, C.J., and Smith A.L., “Introduction to the MultiUAV2 simulation and its application to cooperative control research”, Proceedings of American Control Conference, Vol. 7, 2005, pp. 4490-4501. 7 Castillo, M., Alvis, W., and Castillo, C., “Modeling and visualization of multiple autonomous heterogeneous vehicles”, IEEE International Conference on Systems, Man and Cybernetics, Vol. 3, 2005, pp. 2001-2007. 8 “Bell Helicopter Develops First-Ever Commercial Tiltrotor Using The MathWorks Tools and Model-Based Design”, Vertical Magazine [online journal], April 2006, URL: http://www.verticalmag.com/ [cited 7 August 2006] 9 “Lockheed Martin Aeronautics and The MathWorks Achieve Milestone With Successful F-35 JSF Flight Simulator Test”, Mathworks Press Room [online magazine], January 2004, URL: http://www.mathworks.com/company/pressroom/ [cited 7 August 2006] 10 Gavrilets, V., “Autonomous Aerobatic Maneuvering of Miniature Helicopters”, Ph.D. Dissertation, Massachusetts Institute of Technology, 2003. 11 Vélez, C.M., and Agudelo, A., “Multirate control of an unmanned aerial vehicle”, WSEAS Transactions on Circuits and Systems, Vol. 4, No.11, 2005, pp. 1628-1634. 12 Pollini, L., and Innocenti M., “A Synthetic Environment for Dynamic Systems Control and Distributed Simulation”, IEEE Control System Magazine, Vol. 20, No. 2, 2000, pp. 49-61. 13 Luqi, L., Steigerwald, R., “Rapid software prototyping”, Proceedings of International Conference on System Sciences, Vol. 2, 1992, pp. 470-479. 14 Vélez, C.M., and Salt, J., “Control Multifrecuencia en Tiempo Real Utilizando Herramientas CACSD”, Revista Iberoamericana de Automática e Informática Industrial (RIAI), Vol. 1, No. 3, 2004, pp. 43-52. 15 Multirate Control Toolbox, Software Package, Ver. 5.1, Vélez C.M., URL: http://www.mathworks.com/ matlabcentral/ [cited 7 August 2006] 16 QNX Momentics, Software Package, Ver. 6.3, QNX Software Systems Ltd.. 17 RT-Lab, Software Package, Ver. 7.1.4, OpalRT, Montréal, Canada 18 Martin, R.F.K, “Designing a Real-Time PUMA Controller Using Simulink and QNX”, URL: http://wwwusers.cs.umn.edu/~martin/ [cited 7 August 2006] 19 Rogers, R.M., Applied mathematics in integrated navigation systems, AIAA Education Series, AIAA, 2000. 20 Mettler, B., Identification Modeling and Characteristics of Miniature Rotorcraft, Kluwer Academic Publishers, 2003. 21 Padfield, G.D., Helicopter flight dynamics: the theory and application of flying qualities and simulation modeling, AIAA, 1996. 22 Tischler, M.B., Cauffman M.G., “Frequency-Response Method for Rotorcraft System Identification: Flight Applications to BO-105 Coupled Fuselage/Rotor Dynamics”, Journal of the American Helicopter Society, Vol. 37, No. 3, 1992, pp. 3-17. 23 Cevita, M., Messner, W.C., and Kanade T. “Modeling of small-scale helicopters with integrated first-principles and systemidentification techniques”, Proceedings of the 58th Forum of the American Helicopter Society, 2002, pp. 2505-2516. 24 Hamel, P.G., and Jategaonkar, R.V., “Evolution of flight vehicle system identification”, Journal of Aircraft, Vol. 33, No. 1, 1996, pp. 9-28. 25 Hamel, P.G., Kaletka, J., “Advances in rotorcraft system identification”, Progress in Aerospace Sciences, Vol. 33, 1997, pp. 259-284.

10 American Institute of Aeronautics and Astronautics

The quarterly newsletter for JSBSim, an open source flight dynamics model in C++ VOLUME 3, ISSUE 2 SUMMER 2006

See Page 12:

Building an Aerobatics Aircraft for JSBSim : The Su-26 Enrique Laso Leon

What's the point?

aesthetic judgment!

Pure unlimited aerobatic aircraft have seldom been modeled in any mainstream simulator. Many will argue that the Extra 300 introduced in Microsoft® Flight simulator-98 is a clear proof of the contrary, yet the FS flight model was (and still is) too limited to provide a decent sensation of flying. The most recent aerobatics planes correctly modeled are the SF260 and Spitfire MkXIV from Real Air® but those are not dedicated “stunt airplanes”.

Modeling the Beast Aerobatic aircraft have plenty of features that make them easy to model (which is good since this is my first add-on aircraft for FlightGear):



Straight wing with little taper ratio (this allows

• • • •

using the lifting line theory for 3D wing derivations (Prandtl) Symmetric Airfoils Low Mach number (incompressible flow) Reciprocating engines No high lift devices (lift is obtained through thick airfoils) Simple avionics

The last serious attempt to model this category of aircraft was the first Flight Unlimited simulator back in 1996! It was nicely packaged with a fine tutorial (remember, this was at a time when games came with a manual) and allowed one to fly machines ranging from an aerobatic sailplane to the Su31 unlimited aerobatic aircraft.

Inside this issue: Aerobatics Aircraft: Su-26

1

Scripting Multiple Runs in JSBSim

3

Scripting Changes in JSBSim

6

JSBSim and MSFS

9

News

10

Modeling Aerodynamic Moments

11

OpenEaagles Simulation Framework

12

The 2006 AIAA Modeling and Simulation Conference

14

Simulators Aboard the U.S.S. Lexington Museum at Corpus Christi, Texas

16

Simulate This!

End

Many reasons can be found for the lack of interest in this category. The most obvious is that aerobatic aircraft are limited to Visual Flight Rules since instruments are heavy and sensitive to the kind of flying involved. What's worse, they have a very short range because a routine of 10 minutes of high-g maneuvers will bring the pilot to his (or her) knees, and the less fuel, the better for maneuverability. Finally, performing a correct maneuver requires a lot of training (first loops look awful when replayed!). All this being said, it is an extremely rewarding way to fly as it gives a sense of the third dimension with fine management of potential vs. kinetic energy being the key. Flight modeling is the most important part when recreating the feeling of aerobatic flight. Most of the maneuvers are performed inside or near a stall. Asymmetric stalls are also a key ingredient of maneuvers such as the snap roll. JSBSim already provides a fine experience of flying and, being open source, has the potential to evolve to give the whole envelope. Why did I choose the Su-26? Let us say that it is a matter of personal taste. Sure enough, there are better aircraft around (Cap-232 or the superlative Su31 come to my mind), but one can hardly fight his



Nevertheless as I wrote before, the post-stall envelope must be modeled for the magic to begin and this is were it gets tough. I did not have explicit references for the SU-26 airfoil. The only data I could get was a relative thickness (see The Incomplete Guide to Airfoil Usage, http://www.ae.uiuc.edu/m-selig/ads/aircraft.html). So, I started with a typical symmetric airfoil and scaled it to match a relative thickness of 15%. While this may look like an appalling approximation, thin airfoil theory indicate that the thickness law (which is the only variable for a symmetrical (Continued on page 2)

Page 14

The 2006 AIAA Modeling and Simulation Conference in Keystone, Colorado Jon S. Berndt

I had the opportunity to attend the 2006 American Institute of Aeronautics and Astronautics (AIAA) Modeling and Simulation Technology (MST) Conference this year. It was held at Keystone in Colorado. The location was breathtaking, and the conference was great. The AIAA conference held in August of each year is really a series of four parallel conferences: the Guidance, Navigation, and Control (GNC) Conference; the Atmospheric Flight Mechanics (AFM) Conference; the AIAA/ AAS Astrodynamics Specialist Conference, and the MST Conference, as mentioned. When you register for one conference, you gain access to all the conferences. This year, among the several workshops given, there was one that demonstrated the use of AEROML (a.k.a. DAVE-ML). AERO-ML is a pending AIAA standard that specifies a formal data format as a medium for exchanging aircraft aerodynamic characteristics between different simulations. The workshop speaker was Bruce Jackson (NASA Langley, “LaRCSim” author). I attended this interesting workshop, and even said a few words about the use of XML by JSBSim. Also present at the workshop was Geoff Bryan, an engineer from the Defence Science and Technology Organisation (DSTO), a government research organization in Australia. DSTO has created a software library in C++ called Janus that reads files in AERO-ML format. That library has been recently open

sourced and released. You can read more about Janus (and request a copy) here: http://www.dsto. defence.gov.au/research/4675/. The file format for JSBSim was an early example of the use of XML in describing aircraft aerodynamics. In turn, JSBSim has incorporated some of the features developed for AERO-ML, moving the JSBSim format closer to this emerging standard. There were quite a number of very interesting papers presented during the conference, which ran from August 21 through August 24. Among the more interesting papers submitted were:

• • • • • • •

A Generic Multibody Parachute Simulation Model Adjusting a Helicopter Rotor Blade Element Model to Match Sparse Criteria Data Creating Flight Simulator Landing Gear Models Using Multidomain Modeling Tools Development and Qualification of a FNPT II Helicopter Simulator - Lessons Learned Development of a Pilot-in-the-Loop Aircraft Simulation Laboratory Distributed Real Time Simulation Using DIS and XML Flexible Uses of Simulation Tools in an Academic Environment (Continued on page 15)

AIAA Modeling and Simulation Technologies Conference and Exhibit 2007 Call For Papers Now Open! The call for papers for the AIAA Modeling and Simulation Technologies Conference is now open! Technical Papers are now being solicited in the following suggested topic areas: •Best Student Paper •Unmanned Aerospace Vehicles and Unmanned Systems •Aircraft Dynamics •Aircraft Flying Qualities •Projectile and Missile Dynamics and Aerodynamics •Reentry and Aeroassist Vehicle Technology •Reusable Launch Vehicles •Unsteady and High Angle-of-Attack Aerodynamics •Linear and Nonlinear Equations of Motion •Atmospheric Flight Mechanics Education •Vehicle Flight Test •Invited Sessions and Workshops

This list is intended to provide ideas for papers and is not meant to limit papers to mentioned topics. Prospective authors are invited to electronically submit abstracts of 500–1000 words. The abstract deadline is 1 February 2007. AIAA Guidance, Navigation and Control Conference and Exhibit AIAA Modeling and Simulation Technologies Conference and Exhibit AIAA Atmospheric Flight Mechanics Conference and Exhibit 20-23 August 2007 Marriott Hilton Head Beach and Golf Resort Hilton Head, South Carolina To view the full call for papers, or to submit a paper visit http://www.aiaa.org/events/mst

(Continued from page 14)

• • • • • •



Page 15

Ground Dynamics Model Validation by Use of Landing Flight Test Data High Fidelity Landing Gear Modeling for Real-Time Simulation Modeling of Apparent Mass Effects for the Real-Time Simulation of a Hybrid Airship Modeling, Simulation and Rapid Prototyping of an Unmanned Mini-Helicopter Simulation of Airship Dynamics The Development of the TriTurbofan Airship Model for Autonomous Flight Control Research … and many others.

There were also quite a few papers submitted for UAV modeling and simulation, which is of course a hot topic now. Beginning at 8:00 in the morning on each of the four days, a keynote Above and below: The setting for the 2006 AIAA GNC/MST/AFM/AS conferspeech was given in one of the four conference disciplines (GNC, ences was in Keystone, Colorado. At the beginning of the week, we were told that MST, AFM, and AS). Following that, papers covering related topics it might rain every day. Instead, it was sunny almost every day. Perfect! were presented in a session. It was sometimes hard to choose among individual presentations to attend. For this event, some of the presentation rooms were not in the same building, which required a five or ten minute walk between presentations. Advance and alternate planning is important at conferences. On the last full day of the conference I was invited to attend the Modeling and Simulation Technical Committee (M&S TC) meeting. Within AIAA are a number of Technical Committees. From the AIAA web site: AIAA Technical Committees (TCs) bring together experts in their fields and given them the opportunity to exchange knowledge and get to know their colleagues from around the globe. These committees participate in numerous activities: they develop and administer over 20 technical conferences each year; conduct professional development courses, produce books, and work with K-12 students to promote an interest in engineering education. And that’s just the start. The TCs also honor technical leadership through Technical and Best Paper awards; serve as journal and book reviewers; formulate technology assessment packages for the non-technical public, and even develop and judge college student design contests. I am nominated for membership in the M&S TC. The process and guidelines for membership are being reworked at this time. I plan to attend the next M&S TC meeting in December. Finally, I heartily recommend to technically oriented and educated readers to consider attending the Modeling and Simulation Conference. The conferences are well attended and it’s a “target rich environment” for modeling and simulation information. I met some wonderful people, and the food and location was first-rate. Next year (see the announcement on page 14) the conference will be held at Hilton Head Beach Resort in South Carolina. ▲

Suggest Documents