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.
calculations. We run the FDM at 120hz and compute how many loops can fit into each FG loop.
Floating point rounding could lead to a situation where we could end up running
1, 3, 1, 3, 1, 3... loops of the FDM when in fact we want to run 2, 2, 2, 2, 2...
If we artificially inflate ml above by a tiny amount to get the
closest integer, then subtract the integer from the original
slightly smaller value, we can get a negative remainder.
Logically this should never happen, and we definitely don't want
to carry a negative remainder over to the next iteration, so
never let the remainder go below zero.
src/AIModel/AIAircraft.cxx src/ATC/AILocalTraffic.cxx
src/FDM/flight.cxx src/FDM/flight.hxx src/FDM/groundcache.cxx
src/FDM/groundcache.hxx src/Main/fg_init.cxx src/Main/main.cxx
src/Scenery/hitlist.cxx src/Scenery/hitlist.hxx
src/Scenery/scenery.cxx src/Scenery/scenery.hxx
Make use of the attached SGMaterial reference userdata on scenegraph
leafs. Make the SGMaterial pointer available to the ground query
routines.
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
I had inadvertently terminated a data line when reaching a tab character after
initial data was supplied. I tested the lightning file and it now appears to
read in correctly.
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.
Jon Stockill wrote:
> I've just discovered that when using the null fdm I'm not getting
> updates to /position/ground-elev-m any more. So I can't actually
> retrieve the terrain elevation. Is there somewhere else in the property
> tree I could read this from?
The attached patch fixes this problem.
Erik Hofman:
This patch contains an update to net_ctrls.hxx that adds an extra 100 bytes
(or an equivalent of 25 (u)int32_t types) of reserved space. This could be
used to make the protocol forward and backward compatibel within a certain
scope. Be sure to read the instructions at the begining of the header file
when addinf new variables.
remove a hack and do it properly: if the requested elevation is for some
reason below the surface and the intersection test fails (as it appears
to be the case in EGLL), try again from 10000m ASL
mf: typos
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).
there was the situation where four directories contained jst two files,
of which three directories were aircraft related, and one directory contained
test code from Curt that might be better of in SimGear anyhow.
This is just a patch to move a bunch of files to new locations. In case of
local changes to any of them you can do the following:
move replay.[ch]xx from src/Replay to src/Aircraft
move control.[ch]xx from src/Control to src/Aircraft
move ssgEntityArray.[ch]xx from src/Objects to simgear/screen
In addition it has been decided only to use .[ch]xx files in all directories
unless it's contained within an FDM specific directory, in which case the
author is free to do whatever (s)he wants.
In this repspect the following files have been renamed in src/Multiplayer:
tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx
multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx
CygWin/gcc-3.4.4 updates.
I replaced my cygwin compiler with 3.4.4, did a make clean of plib, simgear,
and flightgear, then did a make install of all three. With the included changes,
everything builds fine, and runs fine.
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.
Using new gcc 4.0 I have some serios warnings about uninitialized
variables, that are used. I created a patch, but I have no idea if it
is possible to do it my way. Can you check this out please?
Erik: I've modified the patch slightly based on the contents of an older
version of hitlist.cxx. I think this is correct now.
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 stumbled across two memory errors with two wrong const references to
std::string.
As I fixed that, I also moved aircraft_dir which is only used from UIUC into
UIUC. With that uiuc_aircraftdir.h is empty and can be removed.
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.
Some quite extensive changes to the AIModel code:
1. Mathias has made major changes to the AICarrier code to provide better
alignment of an aircraft on deck with the carrier - this feature is a major
improvement on the existing, but has a bug which might cause it to fail when
the computer carries out other tasks - changing window size is a known
example. This bug is outwith this code.
2. I have made significant changes to the AIShip code to enable a ship the
turn and roll smoothly.
3. I have added some simple AI which enables the carrier to remain within,
or return to, an operating box.
4. An automated turn into wind for flying operations.
5. A simplistic implementation of TACAN within AICarrier. I am in the course
of implementing this as a generic instrument, but this is some time off
completion.
I have prepared a patch that:
- Introduces a FGTileMgr::scenery_available method which asks the tilemanager
if scenery for a given range around a lat/lon pair is already loaded and make
use of that method at some -9999 meter checks.
- Introduces a FGScenery::get_elevation_m method which queries the altitude at
a given position. In constrast to the groundcache functions this is the best
choice if you ask for one *single* altitude value. Make use of that thing in
AI/ATC classes and for the current views ground level. At the current views
part the groundcache is reused if possible.
- The computation of the 'current groundlevel' is no longer done on the
tilemanagers update since the required functions are now better seperated.
Alltogether it eliminates somehow redundant terrain level computations which
are now superseeded by that more finegrained functions and the existence of
the groundcache. Additionally it introduces an api to commonly required
functions which was very complex to do prevously.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
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.
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
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.
this is basically the past patch I sent to the list and which should now
really (...!?!?) fix the no ground below aircraft problem.
Reasons:
I understood my remaining thinko I introduced with the prevous patch, and the
same thinko I made in my test cases.
The feedback from the list told me that it should help.
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 ...
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
I have some small updates to the ground cache.
- Remove the usage of dynamic_cast where it is known that the result will be
non null.
- Renormalize the surface normal in double precision.
- Place the groundcaches center at the point it was requested not at the
scenery center. This fixes the problems with JSBSim's trimming together with
the ground cache. Now I am ready to commit JSBSim's ground cache usage.
have a "property" mode as well as the original "binary" mode. The property mode
will allow the remote module to request any set of properties, and it will send
those properties each frame. The remote module can reply with a list of arbitrary
property name/value pairs to update on the FlightGear side.
This is a first stab, so it's not the cleanest, most well concieved code, but it
allows an external module (communicating via a pipe) to have a huge amount of
flexibility in the data in can access and update.
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. :)
I still work on getting the YASim models see the detailed environment
especially the carrier.
I have *forgotten* to initialize and to destruct the ground cache object!
Oooopppss!
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.
I have now split out the ground cache functions into src/FDM/groundcache.[ch]xx
Attached are the two files and the patch to integrate that cache into
FGInterface.
The code is nowhere used at the moment, the fdm's need to be updated to use
that ground cache. The JSBSim-dropin.tar.gz from Martins ftp server does this
for example.
The carrier's scenegraph is not yet processed to be visible for ground
intersection testing. So the only benefit up to now is that the api is set
up. Using this I can put the changes to make JSBSim work with that into
JSBSim's cvs. Also I aim to provide Andy a patch to make use of that with
YASim.
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
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.
I have 3 issues that are fixed by this set of patches.
1. In extensions.cxx
#else if !defined( WIN32 ) must be changed by
#elif !defined( WIN32 ) because the text after #else
seems to be ignored
2. banner is not available on windows, only cygwin
3. ANSI escape sequences are not interpreted on the
windows console. We just have garbage that is hard
to read.
