What's the point?
上海市
金汇实验学校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”.
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 Su-31 unlimited aerobatic aircraft.
Many reasons can be found for the lack of interest in this cate-gory. The most obvious is that aerobatic aircraft are limited to Visual Flight Rules since in-struments are heavy and sensi-tive to the kind of flying in-volved. What's worse, they have a very short range
because a routine of 10 minutes of high-g maneu-vers 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 en-ergy 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 ma-neuvers such as the snap roll. JSBSim already pro-vides 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 bet-ter aircraft around (Cap-232 or the superlative Su-31 come to my mind), but one can hardly fight his aesthetic judgment!
Modeling the Beast
2012年浙江高考数学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 deri-vations (Prandtl) •Symmetric Airfoils
•Low Mach number (incompressible flow) •Reciprocating engines
•No high lift devices (lift is obtained through thick airfoils) •
Simple avionics
Nevertheless as I wrote before, the post-stall enve-lope 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 air-foil. The only data I could get was a relative thick-ness (see The Incomplete Guide to Airfoil Usage, 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 approxima-tion, thin airfoil theory indicate that the thickness law (which is the only variable for a symmetrical
(Continued on page 2)
Building an Aerobatics Aircraft for JSBS im : The Su-26
Enrique Laso Leon
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
The quarterly newsletter for JSBSim, an open source flight
dynamics model in C++
S UMMER 2006
V OLUME 3, I SSUE 2
See Page 12:
(Continued from page 1)
airfoil) only influences pressure repartition, not C lift vs. alpha slope (2*π for incompressible
flow). This in turn will change the stall character-istics (abruptness, critical angle, etc.), but I thought the difference would be too small for anybody to notice, provided the airfoil had a rounded leading edge:
The software used to compute the stall character-istics was xfoil (web.mit.edu/drela/Public/web/xfoil) which gave polar curves up to 30 de-
grees of angle of attack.
Post stall behavior derivations was found from an article written for the blades of wind turbines
(Stall coefficient, aerodynamic airfoil coeffi-
cients at large angle of attack, C. Lindenburg réf. ECN-RX-001-04 Energy research center of the
Netherlands).
These computations were made using Open Of-fice Calc v2.0 (any spreadsheet would do for that matter). It should be noted that the curve from 0 to 30 degrees (xfoil) matches quite well with the curve for AOA higher than 30 degrees (post stall).
Derivations for the finite span wing was obtained using the Prandtl theory of the (vortex) lifting line (the one that gives the induced drag as a
function of the aspect ratio). For post-stall behav-ior the article mentioned above provides a correc-tion for finite span. The combination of both pro-vides the following coefficient curves :
It is interesting to notice that the values given by Aeromatic (blue curve on the lift diagram, see for Aeromatic) are not that far from the complete deriva-tion. They would even be better if the airfoil camber effects could be taken into account (at zero camber, i.e. symmetrical airfoil lift at zero incidence is zero).
Drag at zero incidence was increased by impos-ing a minimum value in order to model fuselage drag (very very crude).
The result of all this is an aircraft accomplishing simple aerobatics neatly (barrel rolls, loops, Cu-ban eights) and even complex ones such as the spin with a nice feel. The latter came as a surprise since
sw620细胞JSBSim comes without asymmetric stall effects so far. Snap rolls, while being possible, are somewhat slow and induce a large loss of altitude. Stall on the other hand is extremely brisk with g-loading dropping sud-denly as elevator authority is huge (purposely in order to get adequate五年计划
control all through the envelope)
Future Improvements
The beta version of the Su-26 will be released sometime soon in order to get a first feedback (hopefully from real life pilots, too!).
The model can stand a lot of improvement with
(Continued on page 3)
Page 2
Edited by Jon Berndt
“Back of the Envelope ” is a communication tool written
generally for a wider audience than core JSBSim developers, including instructors, students, and other users. The articles featured will likely tend to address questions and comments raised in the mailing lists and via email. If you would like to suggest (or even author) an article for a future issue, please email the editor at:
**************
About this newsletter ...
(Continued from page 2)
the current definition of JSBSim. The next step is to correctly model the moment coefficient of the whole aircraft (that is, taking the wing and tail separately) for the whole AOA range. This does not require a lot of additional theory, just to take into account the direction of motion (the “focus” is at a quarter of the chord for low incidence, but measured in the direction of the flow !).
Fine tuning of the propeller is really lacking for now. Particularly thrust in the low speed envelope is abundant, making landings quite difficult. Other improvements could come from evolutions
Page 3 of JSBSim, itself. In order to model post stall be-
havior, asymmetric effects could be taken into ac-
count, especially since propeller airplanes will tend
to depart in asymmetric stall due to engine torque
and P-factor.
Furthermore variations of lift along span would
add an extra feeling, since loss of aileron effi-
ciency at low speed is related to wingtips being
more loaded than roots for tapered or swept wings.
But in turn that would have little influence on
aerobatics airplanes as they often have full span
ailerons to handle this problem! ▲
Scripting Multiple Runs in JSBSim Agostino De Marco
A couple of months ago I began to think over the following idea: One may have the need to run JSBSim multiple times and compare the results; would it be worthwhile to implement a new capa-bility into the scripting language supported by JSBSim's FGScript class that would make it possi-ble to launch one or more successive simulations with one single script?
After all, in each of the many scripting languages available today we always find the following ele-ments: conditions (if-then-else clauses), selection (switch clauses), iterations (for clauses), inclusion of blocks of code (include/import clause) etc. Then, what if we had something vaguely similar in JSBSim scripts?
As someone said in the development-issues mail-ing list, there are many reasons for wanting multi-ple runs from a simulation. When designing or modifying a control or guidance system, one may want to evaluate the design at multiple test points within the flight envelope. Having the ability to set up a file with a number of initial conditions, trims, etc. would allow the user to do multiple tests with-out having to play around with a bunch of files. Thinking at the simplest level, suppose that one has prepared N scripts, for example,
737_l, 737_l, ... ,
737_l, that clearly let us guess that the user is trying to simulate different variations of a take off run for the B737 aircraft. According to the above idea, he would like to have the chance to run JSBSim through each of the above cases by using a single script, the "driver", which could be something like: A first problem arises here. After each run this approach should incorporate a "post-run"
step to save the output (if specified), e.g.
B737_datalog.csv, in a number of unique files, i.e. B737_datalog_1.csv, B737_datalog_2.csv, ... ,
B737_datalog_N.csv.
From the coders point of view the development of advanced scripting features would of course become quite demanding, as this job would be like implementing a sort of interpreter on top of
the main JSBSim structure.
Actually, looking more closely at the kind of code that JSBSim is and how it is intended by the developers, even if the above "capability" would be nice to have, one can comment that (quoting Jon Berndt) this is the kind of thing that, in spite of being explicitly provided for in the scripting lan-guage, should be done externally, through a feature in JSBSimCommander or via a shell script. In fact, an application like JSBSim Commander, being that just a "Commander," will hopefully have that abil-ity sooner or later.
Finally I convinced myself that the capability to launch multiple runs of JSBSim, collect output data appropriately, and prepare plots for the analy-sis should not be required to the flight dynamic model,
because this is not his job, but should rather be implemented outside via a shell script. And that's what I did. Eventually, I will also to have an animation (i.e. an .avi file) of the simulation, auto-matically generated.
Multiple runs done in this way are really helping me in the analysis of a number of variants of stan-dard flight maneuvers starting from steady equili-
brated conditions, in flight and
on ground.
Thanks to a grant from
ENAV, the Italian authority
on flight safety, I have ana-
lyzed a number of take off
runs from Milano Linate air-
(Continued on page 4)
<runscript name="B737 takeoff runs" action="MULTIPLE"> <script file="737_l">
<script file="737_l">
<script file="737_l">
<!-- this is just a naive attempt
to -->
</runscript>
Page 4
(Continued from page 3)
port. I have investigated on the possible failures during take-off runs and consequent inadequate pilot reactions/maneuvers that end up with the airplane colliding with a par-ticular radar tower, which is going to be build in the vicinity of the main run-way. For the sake of brevity, I will discuss below, with an annotated example, how I have tackled the most relevant prob-lem from JSBSim users' perspective: running JSBSim a number of times in a row through a shell script. I will reserve some final observations as hints for the development of similar scripts that, from logged output files, generate relevant plots and automati-cally produce a document collecting them. This involves the use of well known, freely available, programs like Gnuplot and LaTeX. Before going on further we ha
ve to note that the 0.9.11 version of JSBSim "suspends" the simu-lation, i.e. the time increment is set to zero when a crash is detected. Consequently, when JSBSim is launched as a stand-alone batched application and the simulation ends up with the aircraft crashing on the ground the program enters into an infinite idle loop and the user must manually kill the corresponding process. The need to work with failure situations during take-off and with scripted runs has required me to modify a little bit JSBSim's main loop in order to have the program execution
terminated each time, with no possibility of suspen-sion.
The code snippet In Code Sample 2 illustrates the modifications I made in JSBSim.cpp.
Multiple runs of JSBSim are now easier to achieve
with a bash (Bourne-Again SHell) shell script. Bash is a command language interpreter that exe-cutes commands read from the standard input
or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh), popular
interpreters from the Unix world. Bash is freely available for all Linux distributions, for Unix and for W
indows (Cygwin). The basic idea behind multiple runs via a bash script (that I'll call "multiple-run.sh") is to concentrate in a given directory a number of JSBSim scripts, e.g. "l", "l",
"l", etc., and have a tool that per-forms the following tasks:
1.list the eligible xml files,
2.put them into an array,
4.launch JSBSim as many times as the number of
cases listed. The unique ID will help to rename and manipulate the output files further. A possible "multiple-run.sh" is listed in Script 1 (see page 5), with appropriate annotations. It is a good idea to put the script resides and give it the usual attributes (execute per-mission) like the following command does:
chmod u+rx ./multiple-run.sh
The multiple runs will be launched with the com-mand, ./multiple-run.sh [The command must be run in the directory where the shell script resides.] Once all JSBSim runs are done (according to the con-tents of the directory <JSBSim root>/test/scripts) the user will find a bunch of output csv files in the JSBSim root dir.
Their names start with a unique numeric code as produced in the script main loop. At this point, it is a straightforward task to pre-pare a script that lists all (Continued on page 6)
Code Sample 2 // *** CYCLIC EXECUTION LOOP, AND MESSAGE READING *** //
while (result) {
while (FDMExec->ReadMessage()) {
msg = FDMExec->ProcessMessage();
switch (msg->type) { case JSBSim::FGJSBBase::Message::eText: { cout << msg->messageId << ": " << msg->text << endl;
// I just warn the user the simulation will be stopped anyway
#if defined(AGO_NO_SUSPEND) // agodemar
string::size_type loc = msg->text.find( "Crash Detected: Simulation STOP", 0 );
if ( loc != string::npos )
cout << ".............. simulation will be stopped " << endl; #endif break; }
}
// ...
if ( ! FDMExec->Holding()) {
if ( ! realtime ) { // IF THIS IS NOT REALTIME MODE, IT IS BATCH
result = FDMExec->Run(); // Here I break and stop the loop avoiding program suspension #if defined(AGO_NO_SUSPEND) if ( FDMExec->GetState()->Getdt()==0.0 ) // check if SUSPENDED after CRASH
break;
#endif
Page 5 #!/bin/bash
# The sha-bang (#!) at the head of the script tells the system
# that the file is a set of commands to be fed to the indicated command interpreter,
# in this case /bin/bash. Thus #! is actually a two-byte magic number
# that designates here an executable shell script
echo "-------------------------------------------------"
echo " Multiple JSBSim runs "
echo "-------------------------------------------------"
echo
# JSBSim root dir, executable name, and working directory
# (change them conveniently for your system)
JSBSim_ROOT="l:/agodemar/jsbsim/JSBSim-0.9.11_dotNET2005/JSBSim/"
JSBSim_EXEC=$JSBSim_"
WORK_DIR="test/scripts/"
# Note: must be a relative path to JSBSim root dir !!
# we will put here the scripts "l", "l", ... etc.
#------------------------------------------------------------------------------------
# collect script file names (from WORK_DIR)
#------------------------------------------------------------------------------------
SCRIPT_FILES0=`ls "$JSBSim_ROOT$WORK_DIR"B737_script*.xml`
# The back ticks `...` return the result of the system command, ls, into a string.
# File names returned here do not include the path.
#------------------------------------------------------------------------------------
# give the scripts a proper name, including the path
#------------------------------------------------------------------------------------
SCRIPT_FILES=
for file in $SCRIPT_FILES0
do
file="$WORK_DIR/"$file # prepend the appropriate path
#echo $file
SCRIPT_FILES="$SCRIPT_FILES"$file" " # collect the names
done
echo "scripts: "$SCRIPT_FILES
echo
#------------------------------------------------------------------------------------
# run JSBSim multiple times
# and generate the unique ID for each run
#------------------------------------------------------------------------------------
prefix=
PREFIXES=
for scriptfile in $SCRIPT_FILES
do
if [ ! -e "$scriptfile" ] # Check if file exists.
then
echo "$scriptfile does not exist."; echo
continue # On to next scriptfile in the list.
fi
# File exists, print name and size
ls -l $JSBSim_ROOT$scriptfile | awk '{ print $9 " file size: " $5 }'
# This is an example of piping (<command 1>|<command 2>):
# $JSBSim_ROOT$scriptfile expands to the name of the current JSBSim script that is to
# be used for the simulation. Command ls -l returns a number of fields, whose 9th and 5th
# are printed by the awk utility (actually on cygwin gawk, Gnu awk, is invoked)
# Now generate a unique id by using the date command
prefix=$(date +%N)
# "+%s" option (GNU-specific): seconds since 1970-01-01 00:00:00 UTC
# "+%N" : nanoseconds (000000000..999999999)
# The following alternative would strip off leading and trailing zeroes, if present.
# prefix=`date +%N | sed -e 's/000$//' -e 's/^0//'`
# by using sed
# store ID in an array
(Continued on page 7)
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议