More realistic calculation of vortices at the blades and therefore
real airfoil parameters can be used now (not to be mixed up with the
vortex ring state which is still not simulated), ground effect is now
continuous e. g. at buildings, calculating of the rotor in more than 4
directions, better documentation of the airfoil parameters.
values that were angles between the aircraft's orientation and the
global velocity vector, not the airflow velocity. So the HUD velocity
vector was wrong when the wind was non-zero. Fix that.
generates a data file of aerodynamic lift and drag (and L/D) against
AoA at a specified speed and altitude through a full circle. Wrote it
to track down the YF-23 superthrust issue, but it wasn't any help.
All the forces look fine.
state. The only really obvious problem was a giant negative engine
RPM, which happened because of a lack of clamping in the engine code
combined with the YF-23's ability to actually reach speeds near the
engines _vMax value. It's not clear to me that this will fix the
superthrust issue at high AoA's, but it's an obvious bug nonetheless.
+ The wing compilation step was accidentally omitting regions that lie
between the tips and the first/last control object. That's a real
problem for wings that contain no controls, and a significant issue
for those that contain only a few. I'm stunned that this went
undetected for so long.
+ The Surface::flapLift() function was oddly returning 1.0 Newtons as
a minimum, instead of zero.
bunch of memory leaks that had accumulated over the years. FlightGear
doesn't currently bother to destroy and recreate a YASim context, but
at least it can do so now without worry.
groundcache addition -- the ground callback doesn't do anything at
solution time, so the ground plane was unset. Valgrind was whining
about this; it's not clear that it was actually causing a problem.
and in the calculation of the launchbar angle (by Vivian).
It also calculates the holdback angle, and sets a Boolean value which
can be used to initiate the release of the catapult strop submodel at
the appropriate moment (new code by Vivian).
control to piston engines that allows external scripts to control the
turbo/supercharger boost programatically by setting this axis to
values in the range [0:1]. It also adds a "turbo-lag" attribute (a
time in seconds) to engines implementing turbocharger spooling delays.
This isn't terribly well tested, but doesn't seem to have broken
anything.
propeller pitch stops for constant speed propellers. The default
values are the same as the previous hard-coded values. The new
attributes, "fine-stop" and "coarse-stop", are documented in the base
package, Docs/README.yasim.
This patch makes use of the vectors now available in simgear with that past
patch. And using that it simplyfies the carrier code somehow.
- Small additional factory's to the quaternion code are done in the simgear
part. Also more explicit unit names in the factory functions.
- The flightgear part makes use of them and simplyfies some computations
especially in the carrier code.
- The data part fixes the coordinate frames I used for the park positions in
the carrier to match the usual ones. I believed that I had done so, but it
was definitly different. Also there are more parking positions avaliable now.
are sharp, as intended. These were are never seen in practice; I
found the problem while looking at 360 degree lift curve graphs
looking for discontinuities.
"jitter" when the aircraft was stopped. This is a fundamental
characteristic of the gear model, and can't be fixed without major
surgery (and not a small amount of blinding insight). But we can at
least clamp it so the value can't change unless the wheel is moving
with a nontrivial velocity (5cm/sec in this case).
Attached is a patch to add oil temperature to the YASim piston engine
model. This brings to life one of the pa28-161's otherwise 'dead'
guages. It's a pretty simple 'model' based on temperatures and warmup
times I've observed in the labs on auto engines and run through my
dodgy-memory filter. It does the job of populating the guage with
something plausible though.
it for the B-29). The gear model itself has supported this always,
but there was no interface from the XML file. Should be backwards
compatible. I don't think I broke anything...
I believe I have found the agl hud problems as well as the 'hole' in the
carrier's deck. I spent half the day to reproduce that problem, it did not
occure when you start on the carrier not does it occure with JSBSim and my
really often used testaircraft. So I really need to improove my helicopter
flying qualities.
I was under the impression that *all* FDM's call
FGInterface::updateGeo*Position(..)
so set the new position in the FDM interface. Therefore I had added at the
some code that updates the scenery elevation below the aircraft to *those*
functions.
Ok, not all FDM's do so :/
The attached patch factors out a function computing the scenery altitude at
the current FDM's position. This function is also used in those FDM's which
need to update this value themselves.
Also this patch restores the nearplane setting and uses the current views
altitude instead of the current aircrafts. I think that this should further
be changed to the eypoint's agl in the future.
The agl is again ok in YASim's hud.
I have traced that reset on carrier problem down to several problems. One of
them is the fact that on reset the carrier is updated while the aircraft is
not. That made the aircraft drop down an elevator sometimes. Depending on the
passed realtime while loading some parts of the scenery.
on RPM via a model developed by Vivian Meazza. Add a "boost" output
to the property tree. Fix a bug where MP would be reported "before"
the wastegate clamping.
2.
I made YASim query the the ground cache at the wrong place. This one fixed
this, one can now land the bo105 on top of the oracle buildings :)
3.
Is a followup of the scenery center update code: Register the scenery center
transform at the time it is put into the scene graph not at creation time.
4.
I held that part back from the past hitlist patch, because I hoped that it
will be sufficient (and the last one was in fact the biggest part) without.
As some test cases from Melchior showed me, it is not. We have additionally
to the wrong computed transform from the prevous patch some roundoff
problems. This patch adds some small tolerance to for the point in triangle
test.
... may be one even needs to increase the eps value further if starting at
some tile boundaries still fails.
5.
That is a big chunk.
Tested now for two days while hunting the second patch :) .
That is a partial rewrite of the groundcache to use its own datastructures for
that flat scenegraph in the cache. The basic advantage is, what Erik
suggested, to precompute some often used values of these triangles. Also
allmost all computations are now in double precision which should decrease
(hopefully fix), together with a similar tolerance for some point in triangle
tests, the problems with 'no ground below aircraft'.
I am playing with octrees for the groundcache, that will finally solve the
performance problem when high triangular count models end up in the
groundcache. This patch is also some prework for those octrees ...
popping up and crashing when the B-29 model is in use. This isn't the
right solution; we should fine the NaN condition. But it's harmless
and allows development with the B-29 to continue.
back, but forgot to put the same fix into the runtime code. Also
added some comments so I don't get confused again the next time I come
through here. :)
currently just returns a lagged normalized value in the range of 0-1 that
is proportional to N1. It's up to the engine gauge to scale to the right
range. This is for lack of a real model of these items so we can have
something to drive the engine gauges.
As I had reported on 2004/8/4 00:02:56 ("yasim + bo105 + vrp + @#%$#@ == argh!")
there must be a bug somewhere in YASim, which is responsible for the Bo105
turning around the FDM origin (nose tip) rather than the CG. Some people assumed
that I was just another victim of the "view offset" illusion, but this wasn't
and isn't the case.
Maik Justus (the rotor man) has now supposedly found the bug in YASim[1].
Look at this code in FDM/YASim/Integrator.cpp:35--66:
Stub in hooks for Propeller feathering controls and the turbo prop "condition"
lever.
I added a line in FGFDM.cpp to force control properties to exist if they
don't already. This way you can specify anything you want and find them
in the property browser, otherwise no one else may create them and you are
stuck.
In PropEngine::solve() the code original sets _running = true at the
beginning and then sets running = false at the end. I changed this to
save the current value at the start, set to true, solve(), and then
restore the original value at the end. That way if we start off with
_running = true, we don't have to hack up the calc() routine which wasn't
using the value anyway.
Finally I added some very initial support to shut down a turbine engine
(_running = false) when the condition lever goes to zero.
the 30 seconds that Maik had originally intended, according to the comment.
This is important for the pending sound and rotor disc changes (and of course
for realism).
"slow/windmilling propeller" regime. I'm happy with the foundations
of the solution, but this hasn't been complete tested yet. The
solution behavior seems fine on the planes I tried.
PistonEngine class has grown an "Engine" superclass. Some other stuff
moved around too, and I cleaned up some property naming while I was in
there. This hasn't been tested very thorougly, hopefully I didn't
break anything.
work on the pa28 idle and without creating ridiculous side effects
(like being able to fly the aircraft with the starter motor, heh).
This one looks pretty good for now, pending work on the propeller to
get its low speed drag in line with reality.
reads the /consumables tree for input to determine weights, but
places output only in /engines/engine[n]/fuel-consumed-lbs where
it gets picked up by the Nasal code.
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.
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.
> > 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 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.
- 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.
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.
- 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.
