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!
