controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
places now use sgCartToGeod() instead of rolling their own
approximation. And YASim is now using exactly the same 3D coordinate
system as the rest of FlightGear is.
the core YASim stuff. Mostly cosmetic: whitespace adjustment, dead
code & meaningless comment removal, a little code motion to better
partition the helicopter handling from the original code (no more
giant if() { ... } around the solver). Added a warning to the parser
to try to eliminate the string booleans that crept in.
There should be NO behavioral changes with this checkin.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse
thrust, increase throttle.
Here's a new FGSimTurbine module. Changes are:
1. Adds starting and stopping functionality
2. Calculate() now calls other functions, based on the engine's state, which gives more readable code.
Until now turbine engines were always running as long as fuel was available. With this new module the engine defaults to OFF. To start with the engine running, the variable FGEngine::Running must be set to true at sim startup. In FlightGear this is done with --prop:/engines/engine[n]/running=true.
To start the engine (on the ground), first set the starter to ON, i.e. FGEngine::Starter is set to true. In FlightGear this is done by toggling /controls/engines/engine[n]/starter to TRUE. Note that the current FlightGear key binding will not work, as it causes the starter to quit when the key is released. A new key binding is needed, without the mod-up.
When N2 reaches 15% or greater, place the fuel cutoff control to FALSE. This is FGEngine::Cutoff. In FlightGear this is done with /controls/engines/engine[n]/cutoff set to FALSE. The engine will then accelerate to idle. Upon reaching idle, the starter is automatically turned off, and the engine is running. There is presently no FlightGear key binding for the fuel cutoff switch.
To shut off the engine, place the fuel cutoff control to TRUE.
If you shut down the engine in flight it will windmill. To airstart you will need at least 15% N2, just as with a ground start. When you have enough N2, place the cutoff control to FALSE and the engine will restart. Note that if you can't get enough N2 by speeding up, you can get it by using the starter.
The reverser still works, and is controlled in FlightGear with /controls/engines/engine[n]/reverser. With the reverser control on (TRUE), the engine will produce negative thrust in proportion to throttle position, i.e. to get more reverse thrust, increase throttle.
now read the config file out of the individual aircraft directory rather
than the collective Aircraft-yasim/ directory (which is now obsolete.)
This requires a corresponding update of the base package cvs.
The Propeller class ignored negative RPM but still returned a torque
value, which ratcheted up a higher and higher negative RPM until drag
overwhelmed the aircraft.
In reality, the propeller should windmill at a reasonable postive RPM,
introducing a constant drag on the aircraft -- the propeller should
*not* stop unless the plane is flying very slowly. That's a future
project.
I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
Square the normalized direction acceleration for the y and z axes, so
that turbulence predominantly affects pitch.
Bind to the /environment/turbulence/magnitude-norm and
/environment/turbulence/rate-hz properties in FlightGear.
This version handles a zero fuel load better. I found that if you try to consume fuel from an empty tank, with zero fuel flow, the FGEngine::Starved flag alternates
> > Here's a patch to add manual-pitch control to the propeller in YASim. A new
> > control axis "PROPPITCH" is added. Requires "manual-pitch" boolean property
> > in the "propeller" tag.
> >
> > Tags and Properties to add in order to enable:
> >
> > manual-pitch="true"
> >
> > <control-input axis="/controls/engines/engine[0]/propeller-pitch"
> > control="PROPPITCH" src0="0" src1="1" dst0="0.40" dst1="0.80"/>
> >
> > Note that for the time being, excessively low RPM or excessively high RPM is
> > brought undercontrol by a scaling range defined in the control-input tag
> > (see "dst0" and "dst1" properties).
I have attached some revisions for the UIUCModel and some LaRCsim.
The only thing you should need to check is LaRCsim.cxx. The file
I attached is a revised version of 1.5 and the latest is 1.7. Also,
uiuc_getwind.c and uiuc_getwind.h are no longer in the LaRCsim
directory. They have been moved over to UIUCModel.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
that after a reset or reposition, several FDM variable were not unbound
correctly and left dangling pointing to unallocated memory. This wasn't
a crash type bug, but those properties then had bogus values. This
specifically prevented the turn coordinator gyro modeling from working after
a reset or reposition.
ttStandard is copied from ttBerndt, with the following modifications:
1. All turbulence is diminished within three wingspans of the ground.
2. The horizontal forces are used to calculate the moments, but then
zeroed out so that only the vertical force is actually applied to
the aircraft.
3. The yaw moment is not used.
In fact, the horizontal forces and the yaw moment should be allowed,
but they are extremely rare compared to the vertical force and the
pitch/roll moments. For now, simply zeroing them gives the most
accurate feel.
FGExternalPipe is destructed.) This leaves the name pipe hanging around
even after flightgear exits, but assuming we put the files in /tmp that
shouldn't be a big deal.
ExternalNet interface:
- allows a much more closely coupled execution. A remote network FDM will run
at it's own rate, and maybe a particular data packets will come, maybe it
won't. This makes it very hard to control timing and keep the animation
smooth. There are also cpu scheduling issues with running multiple
processes on a single machine. The linux scheduler by default runs at
100hz. If an FDM process uses a sleep/alarm system to avoid wasting
CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc. This
makes it *impossible* to serve a display system running at 60hz without
dropping frames.
- the downside is that the FDM process must now run on the same machine as
the master flightgear process.
- NED and UVW are working correctly
- knots is giving true airspeed instead of calibrated airspeed
- mach is not working at all
This desperately needs a trimming routine.
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
really useful unless we simultaneously change the per-iteration deltas
to be smaller. Add another pseudo-tunable to control the speed with
which we change values across iterations. As it turns out, this is
much more effective than the threshold tunable. It does come at the
cost of lower solution performance, however.
Link the standalone executable against the source files explicitly rather
than libYASim, as the Irix linker can't handle the unneeded dependance on
other parts of FlightGear.
isn't well-constrained by the solution process is the drag-vs-aoa curve.
The default value that YASim picked was very steep, and resulted in most
of the jets flying their approaches *way* behind the power curve. This
changes the default to be more forgiving, and adds an "idrag" tunable
to the configuration file for tweakers.
Also, change the default gear springiness to be less stiff.
Changed steering to use the rudder command rather than the rudder
position. During taxi, the rudder trim shouldn't affect the steering
in any serious way.
This should be configurable in the aircraft file, since not all
aircraft use the rudder pedals for ground steering.
[In FlightGear, this may make it easier to taxi straight.]
The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
A bug lurked into our uiuc code.
There are two changes:
[1] Comment out the chunk of code as shown (compare w/ the old)
[2] Put back in the function call, and in that code change AlphaTail to Alpha.
speedups to uiuc_menu.cpp.
(Note these were originally submitted before the cutoff date for new
features, but something was corrupted in the transfer so I granted a bit
of leeway in the schedule.)
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
instrument. This needs to move somewhere permanent.
Also, remove a bogus fuel consumption setting that (1) was off by a factor
of 3600 (hours, not seconds) and (2) collided with identical code in FGFDM.
the amount of drag that the produced lift *would* have produced given an
unflapped air surface. A nifty trick involving the assumption that AoA is
small works for this, and produces plausible results in the high AoA case
as well.
Also, trim for approach using the elevator-trim control, not elevator.
Just cosmetic for current planes, but future ones might have differing
implementations of trim.
(and not the throttle setting), but the recalculation left in a degeneracy
when the target/throttle setting was exactly zero. Zero times a big number
is still zero. Fixed to use real math, not theoretical math.
Fetch all pending remote fdm network packets so there is not chance of
getting behind.
Add support for driving control panel lights.
Working on better modeling KX 155 tuning behavior.
won't apply the right gross weight due to fuel differences.
When solving for zero force, do so in the global frame, not the
aircraft's. In principle, this shouldn't matter (zero is zero in all
frames), but in practice this should help to avoid oscillations.
Calculating lift as force perpendicular to the ground (and not the
wing plane) is clearly the Right Thing, anyway.
Also added support for a /yasim/gross-weight-lbs property, which
should be generically useful.
when the lift/drag are really solid. And defer the approach trim until
the all four of the other variables are perfect. I believe this should
fix the solution failures under gcc 2.95.2.
implicitly in PropEngine by disallowing negative torques, but that was
removed at some point. We really need the explosion protection here
at the source.
This is a new improved patch for the previous tile manager fixes.
Rather than building dependencies between FGlocation or the viewer or fdm with
tilemgr what I ended up doing was linking the pieces together in the Mainloop
in main.cxx. You'll see what I mean...it's been commented fairly well. More
than likely we should move that chunk somewhere...just not sure where yet.
The changes seem clean now. As I get more ideas there could be some further
improvement in organizing the update in tilemgr. You'll note that I left an
override in there for the tilemgr::update() function to preserve earlier
functionality if someone needs it (e.g. usage independent of an fdm or
viewer), not to mention there are a few places in flightgear that call it
directly that have not been changed to the new interface (and may not need to be).
The code has been optimized to avoid duplicate traversals and seems to run
generally quite well. Note that there can be a short delay reloading tiles
that have been dropped from static views. We could call the tile scheduler on
a view switch, but it's not a big deal and at the moment I'd like to get this
in so people can try it and comment on it as it is.
Everything has been resycned with CVS tonight and I've included the
description submitted earlier (below).
Best,
Jim
Changes synced with CVS approx 20:30EDT 2002-05-09 (after this evenings updates).
Files:
http://www.spiderbark.com/fgfs/viewer-update-20020516.tar.gz
or
http://www.spiderbark.com/fgfs/viewer-update-20020516.diffs.gz
Description:
In a nutshell, these patches begin to take what was one value for ground
elevation and calculate ground elevation values seperately for the FDM and the
viewer (eye position). Several outstanding view related bugs have been fixed.
With the introduction of the new viewer code a lot of that Flight Gear code
broke related to use of a global variable called "scenery.cur_elev".
Therefore the ground_elevation and other associated items (like the current
tile bucket) is maintained per FDM instance and per View. Each of these has a
"point" or location that can be identified. See changes to FGLocation class
and main.cxx.
Most of the problems related to the new viewer in terms of sky, ground and
runway lights, and tower views are fixed.
There are four minor problems remaining. 1) The sun/moon spins when you pan
the "lookat" tower view only (view #3). 2) Under stress (esp. magic carpet
full speed with max visibility), there is a memory leak in the tile caching
that was not introduced with these changes. 3) I have not tested these
changes or made corrections to the ADA or External FDM interfaces. 4) The
change view function doesn't call the time/light update (not a problem unless
a tower is very far away).
Details:
FDM/flight.cxx, flight.hxx - FGInterface ties to FGAircraftModel so that it's
location data can be accessed for runway (ground elevation under aircraft)
elevation.
FDM/larsim.cxx, larcsim.hxx - gets runway elevation from FGInterface now.
Commented out function that is causing a namespace conflict, hasn't been
called with recent code anyway.
FDM/JSBSim/JSBSim.cxx, YASim/YASim.cxx - gets runway elevation from
FGInterface now.
Scenery/newcache.cxx, newcache.hxx - changed caching scheme to time based
(oldest tiles discard).
Scenery/tileentry.cxx, tileentry.hxx - added place to record time, changed
rendering to reference viewer altitude in order to fix a problem with ground
and runway lights.
Scenery/tilemgr.cxx, tilemgr.hxx - Modified update() to accept values for
multiple locations. Refresh function added in order to periodically make
the tiles current for a non-moving view (like a tower).
Main/fg_init.cxx - register event for making tiles current in a non-moving
view (like a tower).
Main/location.hxx - added support for current ground elevation data.
Main/main.cxx - added second tilemgr call for fdm, fixed places where viewer
position data was required for correct sky rendering.
Main/options.cxx - fixed segfault reported by Curtis when using --view-offset
command line parameter.
Main/viewer.cxx, viewer.hxx - removed fudging of view position. Fixed numerous
bugs that were causing eye and target values to get mixed up.
the wrong place. The Atmosphere::getStd*() calls are used by the
solver, and thus really need to return values for a "standard"
atmosphere. Otherwise, an aircraft started up in Moscow will behave
differently than one initialized in Cairo. :)
The place where environmental pressure and temperature get inspected
at runtime is in YASim.cxx. The changes there, happily, end up being
even smaller than the ones to Atmosphere. This ends up replacing code
only, and removing some comments.
set_Density; since JSBSim doesn't override the get_* methods from
FGInterface as well, the wrong values are always set anyway.
Take the static temperature, static pressure, and density values from
an external source if requested by the
/environment/params/control-fdm-atmosphere property. This isn't
working properly yet for JSBSim because of interactions with the
trimming routine.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
Due to jumpy joystick read-outs the UFO jitters a lot in turns.
This patch implements simple damping for aileron/elevator/throttle.
Furthermore it lets the UFO fly backwards if brake[0] is active
(by default associated with the joystick's fire button). After all,
everyone knows that UFO's can fly backwards!
It's cumbersome to use the MagicCarpet as 3D cursor, because everytime
you shoot over the target you have first to turn by 180 degrees and to
fly back.
This patch lets the magic carpet fly backwards if brake[0] is active,
which is by default associated with the joystick's fire button.
> I have attached some new additions to the UIUC code. Most of the
> changes allow for the addition of apparent mass. This is very
> useful with light aircraft and gliders.
I have finished working the bugs out of my "Enhanced" version of the Magic
Carpet FDM. The UFO FDM works the same as the Magic Carpet with the
following exceptions:
The aircraft's pitch is determined by the Elevator setting (with a pitch
rate of 45 degrees per second).
Climb is forward velocity * sin(pitch)
Speed is forward velocity * soc(pitch)
Roll is tied to the aileron (again, with a roll rate of 45 degrees per
second)
Turn rate is sin(roll) * 45 degrees.
Yes, this does mean that turning is quite a bit more sluggish than
climbing.
If you are wondering why a UFO FDM, it is because it's best that I not
replace the existing magic carpet and this FDM does behave like a UFO (it
hovers, can spin and pitch while hovering, and does not obey the laws of
physics ;)
- Throttle control position
- Mixture control position
- Magneto/starter control position
Added support for receiving:
- Engine state (off, cranking, running)
- RPM
- Fuel Flow
- EGT
- Oil Temp
- Oil Pressure
- Fuel tank quantity
- Weight on wheels
Changed the steering gain from +/-0.1 to +/-1.0, so that the steering
angle for the nosewheel (when present) is the same as the rudder
deflection angle. That's probably not exactly right, but it's much
better than we had before -- you can now steer the plane on the ground
reasonably during taxiing.
ability to run a nonlinear model with flaps. The files ls_model.c and
uiuc_aero.c were changed since we had some functions with the same
name. The name changes doesn't affect the code, it just makes it a
little easier to read. There are changes in LaRCsim.cxx so UIUC
models have engine sound. Could you send me an email when you receive
this and/or when the changes make it to the CVS? Thanks.
Also I noticed you have some outdated files that are no longer used in
the UIUCModel directory. They are uiuc_initializemaps1.cpp,
uiuc_initializemaps2.cpp, uiuc_initializemaps3.cpp, and
uiuc_initializemaps4.cpp
Rob
for fuselage Surface objects. If the fuselage wasn't aligned perpendicular
to the Y axis, the matrix wouldn't be orthonormal. Since all of, perhaps,
three aircraft have ever been built this way, it's doubtful I would have
found this as a bug report. :)
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
inclueded in some of the files. Irix doesn't have cout in the std class,
so I changed it to "cout" and included SG_USING_NAMESPACE(std) at the
beginning of the files.
And some minor warning cleanups.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
is a work in progress and needs severe enhancement before it will be
useful. It provides a UDP data channel that goes both ways between
flightgear and the fdm. It also provides a TCP 'command' channel so
flightgear can 'reliably' send commands to the remote fdm (such as set
starting position, reset on ground, etc.)
and scaling of control values to properties. Also added a time interpolation
feature that replaces the hacked-in "retract-time" feature for the gear in
a more general way (applicable to flaps, too!). Incompatibly breaks
the XML syntax; get new files!
different locations, and hitched it into FGGlobals. FGEnvironmentMgr
has taken over as the subsystem, while FGEnvironment is simple the
information that it returns. I've removed current_environment
completely -- everything now uses properties or goes through
FGGlobals. FGGlobals itself has a couple of useful methods:
const FGEnvironment * get_environment ();
const FGEnvironment * get_environment (double lat, double lon, double alt);
The first one returns the environment data for the plane's current
position, while the second returns the environment data for any
arbitrary location. Currently, they both return the same information,
but that will change soon.
properties have been renamed from wind-(north|east|down)-fps to
wind-from-(north|east|down)-fps, and the FDMs modified appropriately.
No other changes should be visible unless FG_OLD_WEATHER is defined.
Attached are patches for adding the command line options to set initial
glideslope and climb rate. This was really easy to do as all the pieces
were in place. It works well with JSBSim because the trimming routine
finds the right throttle and elevator settings. It should work with
LaRCsim as well, but it has no trimming routine so there will be some
dynamics at startup. I don't know what YASim will do.
Attached is a fix to add a short period of cranking time required
before the engine fires. I've also added a little hack to limit the
torque applied by the starter motor when the rpm is less than 10 in
order to avoid the rpm overshooting idle in the first time step when
the prop is producing very little resistance due to the low rpm.
I've attached 3 diffs against files in FlightGear to fix some printf
format strings. The changes are pretty straight forward. Let me know
if you have any questions. (BTW, I'm using gcc 2.95.4)
