Arnt Karlsen wrote:
On Tue, 06 Apr 2004 19:41:08 +0200, Erik wrote in message
[EMAIL PROTECTED]:
/gear/nose
..this also works for the big An-226 and B-52 and the Bleriot having
twin nose gear?
..AFAIK, the Bleriot mains are effectively 2 free swiveling nose
wheels, and the tail wheel is
On Tue, 06 Apr 2004 19:41:08 +0200, Erik wrote in message
[EMAIL PROTECTED]:
/gear/nose
..this also works for the big An-226 and B-52 and the Bleriot having
twin nose gear?
..AFAIK, the Bleriot mains are effectively 2 free swiveling nose
wheels, and the tail wheel is effectively a
On Mon, 2004-04-05 at 16:04, Jim Wilson wrote:
As it is now we need to test every
single JSBSim aircraft every time a modification is made to flightgear
because the trim routine is lacks robustness.
Sorry, but this is simply not true.
In this case it is a thing of an interface definition.
If
Mathias Fröhlich wrote:
Suggestion:
Create and give each FGInterface an own subdirectory of the property tree. An
FDM itself should then restrict its accesses to the property tree to values
inside this directory. This would
1. open the possibility of different FDM in the same flightgear
Jon Berndt said:
Thanks for the explanation. This does more than I originally thought.
Would some sanity checks at the JSBSim.cxx level help? I'm not
sure what they
would be, other than the one mentioned before (that relates to
this latest
bug): make sure we have wheels above the
That makes sense. When and if gear compression modeling: will
that complicate this or vice versa?
Do you mean visual modeling of gear compression?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jon Berndt said:
That makes sense. When and if gear compression modeling: will
that complicate this or vice versa?
Do you mean visual modeling of gear compression?
As opposed to? I suppose you could say everything I'm asking about is visual,
since I'm neither a pilot nor an engineer
On Tue, 6 Apr 2004 14:05:38 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon Berndt said:
As opposed to? I suppose you could say everything I'm asking about
is visual,
since I'm neither a pilot nor an engineer :-) It would be nice to
eventually
have the compression values to pull off visual
Jon S Berndt wrote:
On Tue, 6 Apr 2004 14:05:38 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon Berndt said:
As opposed to? I suppose you could say everything I'm asking about is
visual,
since I'm neither a pilot nor an engineer :-) It would be nice to
eventually
have the compression values
On Tue, 06 Apr 2004 16:46:53 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
Jon wrote:
We do have those values. I just never thought about publishing them.
What do you need? What does YASim provide? What would be best?
normalized compression would be great:
gear/gear[]/compression-norm
Erik
Now,
Jon S Berndt wrote:
On Tue, 06 Apr 2004 16:46:53 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
Jon wrote:
We do have those values. I just never thought about publishing them.
What do you need? What does YASim provide? What would be best?
normalized compression would be great:
Jon S Berndt said:
On Tue, 06 Apr 2004 16:46:53 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
Jon wrote:
We do have those values. I just never thought about publishing them.
What do you need? What does YASim provide? What would be best?
normalized compression would be great:
Jim Wilson wrote:
Jon S Berndt said:
Now, the question is how do we match up the 3D model gear strut with
the FDM gear? Is there a common gear numbering scheme? How about gear
that have swiveling bogeys (747, etc.)? Skids (X-15)?
How do you id them in JSBSim? With YASim the gear entries are
On Tue, 06 Apr 2004 18:58:03 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
JSBSim does basically the same (although there is a name allocated
for it), but the real question is: Is left most defined 0, or is
right mos define d0, or is it something completely different
(numbered in order of
Erik Hofman wrote:
JSBSim does basically the same (although there is a name allocated
for it), but the real question is: Is left most defined 0, or is
right mos define d0, or is it something completely different
(numbered in order of appearance)?
Maybe I'm confused: why do we care? The 0
On Dienstag, 6. April 2004 19:32, Erik Hofman wrote:
Jon S Berndt wrote:
They are not now expected to be in any particular order, nor are they
given specific names. The layout is somewhat free form. A questions is,
how do you set up the gear model to support animation when you may want
to
Andy Ross wrote:
Erik Hofman wrote:
JSBSim does basically the same (although there is a name allocated
for it), but the real question is: Is left most defined 0, or is
right most defined 0, or is it something completely different
(numbered in order of appearance)?
Maybe I'm confused: why do we
Erik Hofman wrote:
Jon S Berndt wrote:
They are not now expected to be in any particular order, nor are they
given specific names. The layout is somewhat free form. A questions
is, how do you set up the gear model to support animation when you may
want to model things as varied as a 747, a
Jon S Berndt wrote:
They are not now expected to be in any particular order, nor are they
given specific names. The layout is somewhat free form. A questions is,
how do you set up the gear model to support animation when you may want
to model things as varied as a 747, a C-172, a P-51D, a
On Dienstag, 6. April 2004 19:41, Erik Hofman wrote:
Thinking about it again I think the solutions (for JSBSim) is quite
simple, use the name of the entry (in lower letters) to define the gear:
Good idea.
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
On Tue, 06 Apr 2004 19:41:08 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
/gear/nose
/gear/l_main
/gear/r_main
/gear/tail_skid
/gear/left_top
/gear/right_tip
The only change might be that YASim should allow for defining named
gear locations.
Erik
I don't know anything about how the 3D animation
--- Erik Hofman [EMAIL PROTECTED] wrote:
Erik Hofman wrote:
Jon S Berndt wrote:
They are not now expected to be in any particular order, nor are
they
given specific names. The layout is somewhat free form. A
questions
is, how do you set up the gear model to support animation when
Jon S Berndt said:
On Tue, 06 Apr 2004 18:58:03 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
JSBSim does basically the same (although there is a name allocated
for it), but the real question is: Is left most defined 0, or is
right mos define d0, or is it something completely different
On Tue, 6 Apr 2004 18:05:30 -
Jim Wilson [EMAIL PROTECTED] wrote:
Maybe adding the text description in the gear/gear[n] path (the NOSE,
L_MAIN,
R_MAIN, etc) might help someone trying to figure out which was which.
But of
course they could just look at the config file and count (e.g. R_MAIN
Tony Peden wrote:
--- Erik Hofman wrote:
/gear/nose
/gear/l_main
/gear/r_main
/gear/tail_skid
/gear/left_top
/gear/right_tip
It seems like this would break down pretty quick when faced with all
the variations e.g. a glider, a 172, 747, B-52, DC-10, etc. etc.
Maybe to clear it up a bit, this is
Jon S Berndt wrote:
On Tue, 6 Apr 2004 18:05:30 -
Jim Wilson [EMAIL PROTECTED] wrote:
Maybe adding the text description in the gear/gear[n] path (the NOSE,
L_MAIN,
R_MAIN, etc) might help someone trying to figure out which was which.
But of
course they could just look at the config file and
Erik Hofman wrote:
This way it is easy to change the YASim or the JSBSim or the
animation configuration file to match each other. Fixed (non
compatible numbers) don't allow for that.
I'm not arguing against having names for the gear, which actually
sounds kind of elegant. But it should be
Andy Ross wrote:
Erik Hofman wrote:
This way it is easy to change the YASim or the JSBSim or the
animation configuration file to match each other. Fixed (non
compatible numbers) don't allow for that.
I'm not arguing against having names for the gear, which actually
sounds kind of elegant. But
Jon S Berndt said:
On Tue, 6 Apr 2004 18:05:30 -
Jim Wilson [EMAIL PROTECTED] wrote:
Maybe adding the text description in the gear/gear[n] path (the NOSE,
L_MAIN,
R_MAIN, etc) might help someone trying to figure out which was which.
But of
course they could just look at the
Jim Wilson wrote:
Keep it simple: gear[0], gear[1], gear[2] ...same order as listed in the FDM
config.
Your idea of simple is different then mine. Most of the time I know the
names I've given objects for 3d animations, I never seem to remember the
order in which I put them in the file ...
Erik Hofman said:
Jim Wilson wrote:
Keep it simple: gear[0], gear[1], gear[2] ...same order as listed in the FDM
config.
Your idea of simple is different then mine. Most of the time I know the
names I've given objects for 3d animations, I never seem to remember the
order in which
On Dienstag, 6. April 2004 21:16, Jim Wilson wrote:
Yep. It just depends on how your brain is organized I think :-)
Using names you can also name it gear0, gear1 ...
But using numbers you are fixed to remembering how you configured ...
Greetings
Mathias
--
Mathias Frhlich, email:
On Tue, 6 Apr 2004 19:16:18 -
Jim Wilson [EMAIL PROTECTED] wrote:
Erik Hofman said:
Your idea of simple is different then mine. Most of the time I know the
names I've given objects for 3d animations, I never seem to rememberthe
order in which I put them in the file ...
Yep. It just
On Tuesday 06 April 2004 20:25, Jon S Berndt wrote:
On Tue, 6 Apr 2004 19:16:18 -
Jim Wilson [EMAIL PROTECTED] wrote:
Erik Hofman said:
Your idea of simple is different then mine. Most of the time I know the
names I've given objects for 3d animations, I never seem to rememberthe
On Montag, 5. April 2004 05:30, Jim Wilson wrote:
We should also pick a coordinate origin to report it relative to. If
JSBSim is using the (moving) c.g., then we're both bugged. :)
Umm...I think it's all the same isn't it? It isn't like the ground is
going to move under the FDM's
On Montag, 5. April 2004 03:02, Andy Ross wrote:
I'm happy to dumb down the existing AGL property, but we should pick a
new name for the gear altitude property, which is IMHO a much more
interesting value.
To me there arises the question which gear do you take for this? The nose gear
for
Mathias Fröhlich wrote:
We should also pick a coordinate origin to report it relative to. If
JSBSim is using the (moving) c.g., then we're both bugged. :)
Yep you are right, on my list of improvements to JSBSim there is a 'sensor
location' config option. Not really thought about this in deep
Mathias Fröhlich wrote:
On Montag, 5. April 2004 10:47, Erik Hofman wrote:
Folks, I might be far off here since I'm not a real pilot, but ...
Me too, so I am off too ...
Doesn't the fact that one has to adjust the altitude to match the real
one eliminate the problem? In that case the sensor can
On Montag, 5. April 2004 10:47, Erik Hofman wrote:
Folks, I might be far off here since I'm not a real pilot, but ...
Me too, so I am off too ...
Doesn't the fact that one has to adjust the altitude to match the real
one eliminate the problem? In that case the sensor can be at CG or at
the
On Montag, 5. April 2004 11:05, Erik Hofman wrote:
Prior to takeoff you have to sync your altitude with the ones provided
by ATC. But in fact you synchronize the altitude of the sensor with the
one provided by ATC.
So if ATC says you're at 120 foot, you set the altitude of the sensor to
Mathias Fröhlich said:
On Montag, 5. April 2004 05:30, Jim Wilson wrote:
We should also pick a coordinate origin to report it relative to. If
JSBSim is using the (moving) c.g., then we're both bugged. :)
Umm...I think it's all the same isn't it? It isn't like the ground is
going to
Mathias Fröhlich said:
On Montag, 5. April 2004 03:02, Andy Ross wrote:
I'm happy to dumb down the existing AGL property, but we should pick a
new name for the gear altitude property, which is IMHO a much more
interesting value.
To me there arises the question which gear do you take for
On Montag, 5. April 2004 14:10, Jim Wilson wrote:
Mathias Frhlich said:
On Montag, 5. April 2004 05:30, Jim Wilson wrote:
We should also pick a coordinate origin to report it relative to. If
JSBSim is using the (moving) c.g., then we're both bugged. :)
Umm...I think it's all the
I may be a little slow (monday morning here), but that does not tell me
anything. We are talking about agl not the center of gravity.
Is that the confusion?
I'm not sure, but let me jump in here with a somewhat related comment. Like
I've said before, the FDM naturally solves the rigid body
On Montag, 5. April 2004 14:12, Jim Wilson wrote:
This sounds like it might be excessive. We should continue to model
instrumentation in flightgear.
Fine.
Nothing more on this is needed from the FDM
(we should only be translating to sensor points _if_ the particular
aircraft models the
Mathias Fröhlich said:
On Montag, 5. April 2004 14:10, Jim Wilson wrote:
Mathias Fröhlich said:
On Montag, 5. April 2004 05:30, Jim Wilson wrote:
We should also pick a coordinate origin to report it relative to. If
JSBSim is using the (moving) c.g., then we're both bugged. :)
--- Jon Berndt [EMAIL PROTECTED] wrote:
I may be a little slow (monday morning here), but that does not
tell me
anything. We are talking about agl not the center of gravity.
Is that the confusion?
I'm not sure, but let me jump in here with a somewhat related
comment. Like
I've said
Jon wrote:
For trimming on-ground the AGL value needs to be iterated on until
the lowest point of the aircraft has a positive AGL value.
Tony replied:
Not really. Trimming iterates on altitude and theta until the landing
gear are deflected just the right amount to hold the aircraft up.
--- Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Montag, 5. April 2004 14:12, Jim Wilson wrote:
This sounds like it might be excessive. We should continue to
model
instrumentation in flightgear.
Fine.
Nothing more on this is needed from the FDM
(we should only be translating to
On Montag, 5. April 2004 16:02, Tony Peden wrote:
The trimming routine is not the problem.
Hey, it is not. The problem is that JSBSim relys on a property which is set in
a different way on start than on reset time.
This property changes the 'trimming type' which is used for trimming. So we
need
On Montag, 5. April 2004 16:29, Gene Buckle wrote:
black box. As such, it is no different than any other piece of code:
GIGO.
Just for curiosity: What is GIGO?
Garbage In, Garbage Out.
Thanks. I did not know this one ...
Greetings
Mathias
--
Mathias Fröhlich, email:
--- Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Montag, 5. April 2004 16:02, Tony Peden wrote:
The trimming routine is not the problem.
Hey, it is not. The problem is that JSBSim relys on a property which
is set in
a different way on start than on reset time.
This property changes the
On Montag, 5. April 2004 16:26, Tony Peden wrote:
--- Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Montag, 5. April 2004 16:02, Tony Peden wrote:
The trimming routine is not the problem.
Hey, it is not. The problem is that JSBSim relys on a property which
is set in
a different way on
black box. As such, it is no different than any other piece of code:
GIGO.
Just for curiosity: What is GIGO?
Garbage In, Garbage Out.
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Tony Peden said:
The trimming routine is not the problem.
Jim W. said it himself, the behavior changes when - is set as the
altitude. Well, the only place such logic exists is in src/Main, not
src/FDM. I think eyeballs need to be directed that way. Furthermore,
nothing regarding
On Mon, 5 Apr 2004 14:47:11 -
Jim Wilson [EMAIL PROTECTED] wrote:
What JSBSim does that YASim does not is if the aircraft is a little
too close
to the ground at initialization JSBSim hurls the thing up in the air.
Why is
it that only JSBSim reacts by flipping over the Cessna?
What does
--- Jim Wilson [EMAIL PROTECTED] wrote:
Tony Peden said:
The trimming routine is not the problem.
Jim W. said it himself, the behavior changes when - is set as
the
altitude. Well, the only place such logic exists is in src/Main,
not
src/FDM. I think eyeballs need to be
Mathias Frhlich wrote:
Yes, this is my question.
I also think that this /sim/presets directory should be either built up to the
idea someone noted in this thread before or should be removed. That way noone
can rely on stuff not really maintained ...
The /sim/presets/ stuff is being
On Montag, 5. April 2004 17:45, Curtis L. Olson wrote:
Mathias Frhlich wrote:
Yes, this is my question.
I also think that this /sim/presets directory should be either built up to
the idea someone noted in this thread before or should be removed. That
way noone can rely on stuff not really
Jim Wilson wrote:
What JSBSim does that YASim does not is if the aircraft is a little
too close to the ground at initialization JSBSim hurls the thing up in
the air. Why is it that only JSBSim reacts by flipping over the
Cessna?
YASim does something similar though: it doesn't have a trimming
Mathias Fröhlich wrote:
To me there arises the question which gear do you take for this? The
nose gear for example will have a different agl then any other gear
depending on the orientation of the aircraft.
The lowest one. That's obviously smarter than a real sensor would be,
but that's fine
Andy Ross said:
Jim Wilson wrote:
What JSBSim does that YASim does not is if the aircraft is a little
too close to the ground at initialization JSBSim hurls the thing up in
the air. Why is it that only JSBSim reacts by flipping over the
Cessna?
YASim does something similar though: it
--- Jim Wilson [EMAIL PROTECTED] wrote:
Andy Ross said:
Jim Wilson wrote:
What JSBSim does that YASim does not is if the aircraft is a
little
too close to the ground at initialization JSBSim hurls the thing
up in
the air. Why is it that only JSBSim reacts by flipping over the
On Mon, 5 Apr 2004 11:13:15 -0700 (PDT)
Tony Peden [EMAIL PROTECTED] wrote:
--- Jim Wilson [EMAIL PROTECTED] wrote:
But will we ever know why JSBSim needs to do flip over the 172? :-)
Bad data.
On the part of ... ?
Jon
___
Flightgear-devel mailing
Jon S Berndt said:
On Mon, 5 Apr 2004 11:13:15 -0700 (PDT)
Tony Peden [EMAIL PROTECTED] wrote:
--- Jim Wilson [EMAIL PROTECTED] wrote:
But will we ever know why JSBSim needs to do flip over the 172? :-)
Bad data.
On the part of ... ?
It must be something Tony did ;-)
Best,
The onground property is now ok.
You can reset now JSBSim aircraft.
Thanks for the fix!
Greetings
Mathias
--
Mathias Frhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On Mon, 5 Apr 2004 23:15:42 +0200
Mathias Frhlich [EMAIL PROTECTED] wrote:
The onground property is now ok.
You can reset now JSBSim aircraft.
Thanks for the fix!
??
Was it bad data?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Bad data.
On the part of ... ?
I'll attempt an explanation. If I'm wrong maybe Tony can add two words. OK,
one and a half.
1) A JSBSim airplane can only be placed on the ground after going through an
iterative routine to lower it and adjust it's body angle to balance-out the
forces at
Jon S Berndt said:
On Mon, 5 Apr 2004 23:15:42 +0200
Mathias Fröhlich [EMAIL PROTECTED] wrote:
The onground property is now ok.
You can reset now JSBSim aircraft.
Thanks for the fix!
??
Was it bad data?
All that was bad was a flag caused the trim routine to be called or not
On Mon, 5 Apr 2004 23:04:16 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon S Berndt said:
??
Was it bad data?
I think, that maybe this could be resolved by doing as Andy described
earlier.
In other words know where the gear is and get it above the pavement
(ground
elevation) before the
On Mon, 2004-04-05 at 07:01, Jon Berndt wrote:
Jon wrote:
For trimming on-ground the AGL value needs to be iterated on until
the lowest point of the aircraft has a positive AGL value.
Tony replied:
Not really. Trimming iterates on altitude and theta until the landing
gear are
On Mon, 2004-04-05 at 16:04, Jim Wilson wrote:
Jon S Berndt said:
On Mon, 5 Apr 2004 23:15:42 +0200
Mathias Fröhlich [EMAIL PROTECTED] wrote:
The onground property is now ok.
You can reset now JSBSim aircraft.
Thanks for the fix!
??
Was it bad data?
All that
On Mon, 2004-04-05 at 14:30, David Culp wrote:
Bad data.
On the part of ... ?
I'll attempt an explanation. If I'm wrong maybe Tony can add two words. OK,
one and a half.
1) A JSBSim airplane can only be placed on the ground after going through an
iterative routine to lower it
On Mon, 2004-04-05 at 07:32, Mathias Fröhlich wrote:
On Montag, 5. April 2004 16:26, Tony Peden wrote:
--- Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Montag, 5. April 2004 16:02, Tony Peden wrote:
The trimming routine is not the problem.
Hey, it is not. The problem is that JSBSim
On Mon, 2004-04-05 at 01:23, Mathias Fröhlich wrote:
On Montag, 5. April 2004 03:02, Andy Ross wrote:
I'm happy to dumb down the existing AGL property, but we should pick a
new name for the gear altitude property, which is IMHO a much more
interesting value.
To me there arises the question
Tony Peden said:
On Mon, 2004-04-05 at 16:04, Jim Wilson wrote:
Jon S Berndt said:
On Mon, 5 Apr 2004 23:15:42 +0200
Mathias Fröhlich [EMAIL PROTECTED] wrote:
The onground property is now ok.
You can reset now JSBSim aircraft.
Thanks for the fix!
??
Thanks for the explanation. This does more than I originally thought.
Would some sanity checks at the JSBSim.cxx level help? I'm not
sure what they
would be, other than the one mentioned before (that relates to
this latest
bug): make sure we have wheels above the ground. To test that
Mathias Fröhlich said:
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new FGTrim(fdmex,tGround);
} else {
Jon Berndt said:
So what happens is that on reset, the ground elevation gets
plugged into the
FDM as a starting altitude, and the altitude is then too low (by a few to
several feet depending on the aircraft).
I'm thinking that one thing which *could* play into a solution is measuring
On Sonntag, 4. April 2004 17:49, Jim Wilson wrote:
Mathias Frhlich said:
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
On Sonntag, 4. April 2004 17:59, Jim Wilson wrote:
In any case, the VRP values in the config do not affect the output of the
FDM, right?
Right. I have found that this essential change has sliped through. It is in my
queue to Jon. I guess it will not get lost ...
As far as this problem is
Jim Wilson said:
Mathias Fröhlich said:
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new
Jim Wilson wrote:
One thing I noticed is the altitude-agl is reported at the gear
level by YASim, where JSBSim reports the distance of the nose above
the ground. I'm not sure one is better than the other, but perhaps
this should be standardized.
I interpreted the agl level as a cooked
Andy Ross said:
Jim Wilson wrote:
One thing I noticed is the altitude-agl is reported at the gear
level by YASim, where JSBSim reports the distance of the nose above
the ground. I'm not sure one is better than the other, but perhaps
this should be standardized.
I interpreted the agl
Jim Wilson wrote:
My understanding is the agl should simply be the fdm's altitude-ft
less the ground elevation-ft directly under the aircraft. I'm not
sure by your response if you are aware that the agl in
altitude-agl is above ground level.
Of course. But the agl definition you posit is
Andy Ross said:
Jim Wilson wrote:
My understanding is the agl should simply be the fdm's altitude-ft
less the ground elevation-ft directly under the aircraft. I'm not
sure by your response if you are aware that the agl in
altitude-agl is above ground level.
Of course. But the agl
Hi Jon,
Well I've found that the if the /sim/preset/altitude-ft is set to - then
the trimming works normally. This property is set by no less than three
different functions now and there are a few others that have commented out
code for setting this preset. On the surface this whole presets
So what happens is that on reset, the ground elevation gets
plugged into the
FDM as a starting altitude, and the altitude is then too low (by a few to
several feet depending on the aircraft).
I'm thinking that one thing which *could* play into a solution is measuring
the Z distance between
Well, my first guesses were wrong, but I have found what JSBSim does now:
The code in question is in FGJSBSim::do_trim():
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new FGTrim(fdmex,tGround);
} else {
fgtrim = new
89 matches
Mail list logo
