that overrides in JSBSim will work (i.e. properties can be set)
- modified set_(u|v|w)Body to use set_Velocities_Wind_Body, so
that overrides in JSBSim will work (i.e. properties can be set)
He writes:
Here are the final changes to add threads to the tile loading. All the
thread related code is in the new FGTileLoader class.
./configure.in
./acconfig.h
Added --with-threads option and corresponding ENABLE_THREADS
definition. The default is no threads.
./src/Scenery/tilemgr
Removed load_queue and associated references. This has been replaced by
a new class FGTileLoader in FGNewCache.
Made the global variable global_tile_cache a member.
schedule_needed(): removed global_tile_cache.exists() tests since
sched_tile() effectively repeats the test.
initialize_queue(): removed code that loads tiles since this is now
performed by FGTileLoader.
update(): ditto
./src/Scenery/newcache
Added new class FGTileLoader to manage tile queuing and loading.
tile_map typedefs are private.
exists() is a const member function.
fill_in(): deleted
load_tile(): added.
./src/Scenery/FGTileLoader
The new threaded tile loader. Maintains a queue of tiles waiting to be
loaded and an array of one or more threads to load the tiles. Currently
only a single thread is created. The queue is guarded by a mutex to
synchronize access. A condition variable signals the thread when the
queue is non-empty.
CLO: I made a few tweaks to address a couple issues, hopefully what we
have is solid, but now we kick it out to the general public to see. :-)
The files in the attached tarball make the following changes to
FlightGear:
- rename the existing FGInterface::init() method to
FGInterface::_setup to get it out of the way
- move *all* FDM initialization code out of src/Main/fg_init.cxx and
into FGInterface::init(), and clean up fg_init.cxx a little
(especially by removing the zillions of attempts to place the plane on
the ground at various locations in the code)
- modify FGInterface::bind() so that no values are picked up
automatically at bind time (they are set previously by init() instead)
- modify the init() methods of the classes derived from FGInterface
(i.e. larcsim, jsbsim, balloon, magic, and ada) to invoke
FGInterface::init() explicitly before doing their own setup
I don't claim that the code in FGInterface::init() is optimal (or even
correct), but it seems to work for on-ground starts with both LaRCSim
and JSBSim on runways pointing various directions from near sea level
to about 700' ASL (the range I happened to test). I expect that Jon
and Tony will want to look at the code and refactor and correct it now
that they can see what's going on in one place.
Here's a quick outline of what is invoked:
cur_fdm_state = new <whatever>(dt);
cur_fdm_state->init();
cur_fdm_state->bind();
The constructor allocates memory and sets default values only (with
the help of the FGInterface::_setup() method). The init() method pull
any required properties out of the property tree and sets up the
initial state of the FDM. The bind() method takes ownership of
FDM-related properties so that the FDM can publish them to the rest of
the sim.
Note that bind() and init() are virtual, so any implementation in a
subclass will hide the implementation in FGInterface; that's why
subclass implementations of init() and bind() have to invoke
FGInterface::init() and FGInterface::bind() explicitly, probably at
the start, so that they get the basic initialization.
hope, with earlier versions as well)
- support for the new LONG value type
- gear support for UIUC (updated for the newly renamed SG_* stuff;
otherwise identical to what I sent you before)
- fixed reported MSVC problem in src/FDM/flight.cxx
I have created a set of patches to provide configurable landing gear
for the UIUC models. The patches (including four new files) are
available at
http://megginson.com/private/fgfs/uiuc-20010309.tar.gz
A modified UIUC configuration file for the Twin Otter (DHC-6) is
available at
http://megginson.com/private/fgfs/aircraft.dat
It should be possible to configure appropriate gear for all of the
UIUC models now. As a bonus, the models also support braking, both
absolute and differential, as well as nose-wheel steering (all of
which are currently missing from the UIUC models) -- when you land,
you don't have to keep rolling off the end of the runway anymore, and
you don't have to bank to steer in a taxi.
My sample configuration file contains absolutely bizarre, wild
guesses, and many places that I didn't even bother to guess properly.
The only actual data I had was the wing-span of the DHC-6 (65ft),
which I used for positioning the wing tips. The wing-tips for this
model actually work now -- I hit the aileron hard while accelerating
for take-off, and the wingtip noticeably strikes the ground and
bounces up (quite dramatic in external view using the DHC-6 model from
Wolfram's site).
Details
-------
The UIUC models now support up to 16 gear points each where a gear
point is anything in the aircraft that can come in contact with the
ground, including the tail and wing-tips. I have added the following
new fields to the UIUC configuration files, where <index> is an
integer between 0 and 15, and <value> is a real number:
gear <index> Dx_gear <value> # x offset from CG [ft]
gear <index> Dy_gear <value> # y offset from CG [ft]
gear <index> Dz_gear <value> # z offset from CG [ft]
gear <index> cgear <value> # spring damping [lbs/ft/sec]
gear <index> kgear <value> # springiness [lbs/ft]
gear <index> muGear <value> # rolling coefficient
gear <index> strutLength <value> # gear travel [ft] (not yet used)
Most of these names were already pencilled into the UIUC documentation
(as TODO items), but I had to make up Dx_gear, Dy_gear, and Dz_gear --
if those are inappropriate, I'd appreciate suggestions for better
names.
It will be necessary to modify the other UIUC configuration files to
include some kind of gear support as well, or the planes will sink
nose-first into the ground down to their CG's (it's actually quite
funny to watch with an external view).
Background
----------
As I frequently remind everyone here, I have no math background worth
spitting at, so I will not even pretend to have done the hard stuff.
The UIUC code uses a copy of a very old version of the LaRCsim
c172_gear.c -- I wanted to update it with Tony Peden's excellent newer
version, which includes differential braking among other goodies (the
UIUC models don't support brakes, period).
I copied the newer code into uiuc_aero.c, and it compiled and ran, but
all of the planes ended up sitting on their tails with their noses in
the air. Since Tony made his gear code nicely parameterized, I
experimented with different values, and found that it wasn't too hard
to balance the Twin Otter by moving the gear back a bit. At first, I
used properties to set different values, but then I decided to
integrate the whole thing properly into the UIUC configuration
framework. Thanks to Tony Peden, who did the real modelling work -- I
can take credit only for two or three hours of integration. It turns
out that Tony's code is generalized enough to deal with a wide range
of different gear structures -- I suspect that it will even work for
the 747, when I get around to trying some values.
implicitly correcting for that yet. The plane now makes it to 11000ft on
autopilot *slowly*. I think I'll have to look at the prop parameters
next - altering the diameter and blade angle just slightly can have
quite an effect. If you want to play then try changing the values
prop_diameter and blade_angle in FGNewEngine::init. Keep blade
angle between 20 and 25 (since those are the only values for which
I've entered data and I interpolate between them) and ignore
FGProp1_Blade_Angle since that's an old variable that isn't used. I
really ought to read all the engine and prop parameters from file to
avoid recompilation when tweaking !
the actual air pressure and temperature from the LaRCSim model
instead of assuming that it is at sea level as before. This has
reduced the ceiling from over 60000 ft to about 9000 ft. This is a bit
low (should be around 13 - 14000 ft I think) but I still have some
stuff to do with the engine power correlation and its ignoring the
temperature at the moment so I'm not panicking yet :-)
I've also changed the mixture-power correlation to one from a
published paper since the curve from the IO360 manual seemed to
be a load of rubbish, and didn't have any numbers on the mixture
axis anyway.
I've also knocked the full rich mixture down a touch in line with
Riley Rainey's recommendation, and cleaned up the code a bit.
Added fuel-flow and total fuel to the LaRCSim model. Its still a bit
rough for now but it works, except the engine dosn't stop when fuel runs
out at the moment since there's no refuelling capability in the sim just
now. It takes about 4 gallons use before you see the fuel guages begin
to drop since there's 28 gal per tank but the guages go to 26.
Basically I've rewritten the prop model along similar lines to how
Jon has done his - using published efficiency and coefficient of
power data. It works *much* better - try pulling the throttle back
to idle and putting the plane into a dive before and after updating
and you'll see what I mean. It doesn't require a fudge factor either
:-)
FGOptions is history, and the modules are (starting) to use the property
manager directly. Let me know if I left any files out.
Inevitably, there will be some problems with broken options, etc.,
that I haven't found in my tests, but I'll try to fix them quickly.
We also need to stress that the property names currently in use are
not stable -- we need to reorganize them a bit for clarity.
bring EGT down to a more reasonable range. EGT is now returned in
deg Fahrenheit (yuk!!) by the accessor function since that is what
the guage is calibrated in, and the absolute max value that can be
output (max power mixture at max power) is about 750 deg F. Dave, I
suggest that you set the guage to run from 450 - 750 deg F between
the four big marker ticks. What do the offset and scale actually
refer to in the .xml config file BTW?
Fuel flow, better handling of manifold pressure wrt engine speed, and
proper consideration of altitude effects next, hopefully.
temperature. The cylinder head is assumed to be at uniform
temperature. Obviously this is incorrect, but it simplifies things a
lot, and we're just looking for the behaviour of CHT to be correct.
Energy transfer to the cylinder head is assumed to be one third of the
energy released by combustion at all conditions. This is a reasonable
estimate, although obviously in real life it varies with different
conditions and possibly with CHT itself. I've split energy transfer
from the cylinder head into 2 terms - free convection - ie convection
to stationary air, and forced convection, ie convection into flowing
air. The basic free convection equation is: dqdt = -hAdT Since we
don't know A and are going to set h quite arbitarily anyway I've
knocked A out and just wrapped it up in h - the only real significance
is that the units of h will be different but that dosn't really matter
to us anyway. In addition, we have the problem that the prop model
I'm currently using dosn't model the backwash from the prop which will
add to the velocity of the cooling air when the prop is turning, so
I've added an extra term to try and cope with this.
In real life, forced convection equations are genarally empirically
derived, and are quite complicated and generally contain such things
as the Reynolds and Nusselt numbers to various powers. The best
course of action would probably to find an empirical correlation from
the literature for a similar situation and try and get it to fit well.
However, for now I am using my own made up very simple correlation
for the energy transfer from the cylinder head:
dqdt = -(h1.dT) -(h2.m_dot.dT) -(h3.rpm.dT)
where dT is the temperature different between the cylinder head and
the surrounding air, m_dot is the mass flow rate of cooling air
through an arbitary volume, rpm is the engine speed in rpm (this is
the backwash term), and h1, h2, h3 are co-efficients which we can play
with to attempt to get the CHT behaviour to match real life.
In order to change the values of CHT that the engine settles down at
at various conditions, have a play with h1, h2 and h3. In order to
change the rate of heating/cooling without affecting equilibrium
values alter the cylinder head mass, which is really quite arbitary.
Bear in mind that altering h1, h2 and h3 will also alter the rate of
heating or cooling as well as equilibrium values, but altering the
cylinder head mass will only alter the rate. It would I suppose be
better to read the values from file to avoid the necessity for
re-compilation every time I change them.
LaRCsim c172 on-ground and in-air starts, reset: all work
UIUC Cessna172 on-ground and in-air starts work as expected, reset
results in an aircraft that is upside down but does not crash FG. I
don't know what it was like before, so it may well be no change.
JSBSim c172 and X15 in-air starts work fine, resets now work (and are
trimmed), on-ground starts do not -- the c172 ends up on its back. I
suspect this is no worse than before.
I did not test:
Balloon (the weather code returns nan's for the atmosphere data --this
is in the weather module and apparently is a linux only bug)
ADA (don't know how)
MagicCarpet (needs work yet)
External (don't know how)
known to be broken:
LaRCsim c172 on-ground starts with a negative terrain altitude (this
happens at KPAO when the scenery is not present). The FDM inits to
about 50 feet AGL and the model falls to the ground. It does stay
upright, however, and seems to be fine once it settles out, FWIW.
To do:
--implement set_Model on the bus
--bring Christian's weather data into JSBSim
-- add default method to bus for updating things like the sin and cos of
latitude (for Balloon, MagicCarpet)
-- lots of cleanup
The files:
src/FDM/flight.cxx
src/FDM/flight.hxx
-- all data members now declared protected instead of private.
-- eliminated all but a small set of 'setters', no change to getters.
-- that small set is declared virtual, the default implementation
provided preserves the old behavior
-- all of the vector data members are now initialized.
-- added busdump() method -- FG_LOG's all the bus data when called,
useful for diagnostics.
src/FDM/ADA.cxx
-- bus data members now directly assigned to
src/FDM/Balloon.cxx
-- bus data members now directly assigned to
-- changed V_equiv_kts to V_calibrated_kts
src/FDM/JSBSim.cxx
src/FDM/JSBSim.hxx
-- bus data members now directly assigned to
-- implemented the FGInterface virtual setters with JSBSim specific
logic
-- changed the static FDMExec to a dynamic fdmex (needed so that the
JSBSim object can be deleted when a model change is called for)
-- implemented constructor and destructor, moved some of the logic
formerly in init() to constructor
-- added logic to bring up FGEngInterface objects and set the RPM and
throttle values.
src/FDM/LaRCsim.cxx
src/FDM/LaRCsim.hxx
-- bus data members now directly assigned to
-- implemented the FGInterface virtual setters with LaRCsim specific
logic, uses LaRCsimIC
-- implemented constructor and destructor, moved some of the logic
formerly in init() to constructor
-- moved default inertias to here from fg_init.cxx
-- eliminated the climb rate calculation. The equivalent, climb_rate =
-1*vdown, is now in copy_from_LaRCsim().
src/FDM/LaRCsimIC.cxx
src/FDM/LaRCsimIC.hxx
-- similar to FGInitialCondition, this class has all the logic needed to
turn data like Vc and Mach into the more fundamental quantities LaRCsim
needs to initialize.
-- put it in src/FDM since it is a class
src/FDM/MagicCarpet.cxx
-- bus data members now directly assigned to
src/FDM/Makefile.am
-- adds LaRCsimIC.hxx and cxx
src/FDM/JSBSim/FGAtmosphere.h
src/FDM/JSBSim/FGDefs.h
src/FDM/JSBSim/FGInitialCondition.cpp
src/FDM/JSBSim/FGInitialCondition.h
src/FDM/JSBSim/JSBSim.cpp
-- changes to accomodate the new bus
src/FDM/LaRCsim/atmos_62.h
src/FDM/LaRCsim/ls_geodesy.h
-- surrounded prototypes with #ifdef __cplusplus ... #endif , functions
here are needed in LaRCsimIC
src/FDM/LaRCsim/c172_main.c
src/FDM/LaRCsim/cherokee_aero.c
src/FDM/LaRCsim/ls_aux.c
src/FDM/LaRCsim/ls_constants.h
src/FDM/LaRCsim/ls_geodesy.c
src/FDM/LaRCsim/ls_geodesy.h
src/FDM/LaRCsim/ls_step.c
src/FDM/UIUCModel/uiuc_betaprobe.cpp
-- changed PI to LS_PI, eliminates preprocessor naming conflict with
weather module
src/FDM/LaRCsim/ls_interface.c
src/FDM/LaRCsim/ls_interface.h
-- added function ls_set_model_dt()
src/Main/bfi.cxx
-- eliminated calls that set the NED speeds to body components. They
are no longer needed and confuse the new bus.
src/Main/fg_init.cxx
-- eliminated calls that just brought the bus data up-to-date (e.g.
set_sin_cos_latitude). or set default values. The bus now handles the
defaults and updates itself when the setters are called (for LaRCsim and
JSBSim). A default method for doing this needs to be added to the bus.
-- added fgVelocityInit() to set the speed the user asked for. Both
JSBSim and LaRCsim can now be initialized using any of:
vc,mach, NED components, UVW components.
src/Main/main.cxx
--eliminated call to fgFDMSetGroundElevation, this data is now 'pulled'
onto the bus every update()
src/Main/options.cxx
src/Main/options.hxx
-- added enum to keep track of the speed requested by the user
-- eliminated calls to set NED velocity properties to body speeds, they
are no longer needed.
-- added options for the NED components.
src/Network/garmin.cxx
src/Network/nmea.cxx
--eliminated calls that just brought the bus data up-to-date (e.g.
set_sin_cos_latitude). The bus now updates itself when the setters are
called (for LaRCsim and JSBSim). A default method for doing this needs
to be added to the bus.
-- changed set_V_equiv_kts to set_V_calibrated_kts. set_V_equiv_kts no
longer exists ( get_V_equiv_kts still does, though)
src/WeatherCM/FGLocalWeatherDatabase.cpp
-- commented out the code to put the weather data on the bus, a
different scheme for this is needed.
ing features:
a) ADA Flight model - ADA.cxx, ADA.hxx, flight.hxx
b) Fighter a/c HUD - flight.hxx, hud.hxx, hud.cxx, cockpit.cxx, hud_ladr.c
xx, hud_card.cxx
c) 3-window display - options.hxx, options.cxx, viewer.cxx
d) Moving objects (ship) - main.cxx
e) Patches - main.cxx
ADA.cxx, ADA.hxx
--------------------------
Interface to the external ADA flight dynamics package.
flight.hxx
----------
Included prototypes for accepting additional data fron the External flight
model for fighter aircraft HUD
Hud.hxx
-------
Included prototypes for accepting additional data for fighter HUD from Exernal F
light model.
Defined FIGHTER_HUD pre-processor directive to enable compilation of fighter hud
code.
hud.cxx, cockpit.cxx, hud_ladr.cxx, hud_card.cxx
---------------------------------------
Included code to initialise additional reticles/text for fighter HUD which is co
nditionally
compiled if FIGHTER_HUD is defined.
options.hxx
-----------
Added window_offset, and function to retrieve its value for 3 windows
options.cxx
-----------
Changed few options to suit ADA/CEF projection system/screens and checks for win
dow offset.
views.cxx
---------
Added code to retrieve view offset for window.
Main.cxx
--------
Added code to load and move an aircraft carrier.
Patch to enable clouds from command line until Curtis fixes it. By default cloud
s are disabled.
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
