This gets fixed by this patch:
--- /home/erik/src/CVS/fgfs/JSBSim/FGLGear.cpp
Fri Jan 25 21:10:22 2002
+++ FGLGear.cpp Thu Feb 14 11:26:01 2002
@@ -189,9 +189,11 @@
if (isRetractable) {
if (FCS-GetGearPos() 0.01) {
+ FCS-SetGearPos(0.0);
GearUp = true;
GearDown
Tony Peden writes:
OK, I've figured out what the problem is.
At intialization both the altitude and runway altitude are set:
Start common FDM init
...initializing position...
FGJSBsim::set_Longitude: -2.0444
FGJSBsim::set_Latitude: 0.572695
cur alt (ft) = 0
FGJSBsim::set_Altitude:
Where in the code is the gear position (i.e. relative to retracted or
extended) calculated and managed?
Curt.
Tony Peden writes:
On Fri, 2002-02-15 at 01:49, Erik Hofman wrote:
This gets fixed by this patch:
--- /home/erik/src/CVS/fgfs/JSBSim/FGLGear.cpp
Fri Jan 25 21:10:22
Question: Who's responsibility is it (or should it be) to set the
runway elevation inside of FGInterface?
JSBSIm does fine on its own by using a runway elevation (or scenery elevation,
or whatever) of zero - assuming sea level operations only, for now. JSBSim
defaults to sea level in
Where in the code is the gear position (i.e. relative to retracted or
extended) calculated and managed?
Curt.
The gear forces and moments are calculated in individual instances of
FGLGear. The ground reactions as a whole are managed in FGGroundReactions.
Jon
[EMAIL PROTECTED] writes:
Question: Who's responsibility is it (or should it be) to set the
runway elevation inside of FGInterface?
JSBSIm does fine on its own by using a runway elevation (or scenery
elevation, or whatever) of zero - assuming sea level operations
only, for now. JSBSim
I didn't mean to evoke a defensive response.
[That's just how I write, sometimes. I wasn't being defensive - though it
came across that way - just argumentative. :-)]
The question is, who should be updating the values inside of
FGInterface (which are really inside the JSBSim class since
We should also investigate why FlightGear is
reporting one elevation
initially and then amending it to something else
later ... there's
something not quite right there either. That
investigation isn't
going to happen though before 0.7.9.
This, it seems to me, is the root cause of the
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Where in the code is the gear position (i.e.
relative to retracted or
extended) calculated and managed?
src/FDM/JSBSim/filtersjb/FGKinemat
Curt.
Tony Peden writes:
On Fri, 2002-02-15 at 01:49, Erik Hofman wrote:
This gets fixed by
Curtis L. Olson writes:
The question is, who should be updating the values inside of
FGInterface (which are really inside the JSBSim class since JSBSim
inherits from FGInterface.) This is what JSBSim is using for runway
elevation and is what is not getting updated when starting at KMYF.
Curtis L. Olson writes:
What code determines whether the gear is retracted or extended or in
some intermediate state?
That's FDM-specific. In FGControls, we keep the position of the gear
selector (up or down), but not the actual gear position (likewise for
flaps).
All the best,
David
BERNDT, JON S. (JON) (JSC-EX) (LM) writes:
Where in the code is the gear position (i.e. relative to retracted or
extended) calculated and managed?
Curt.
The gear forces and moments are calculated in individual instances of
FGLGear. The ground reactions as a whole are managed
Curtis L. Olson wrote:
JSBSim properly handles updating the runway/ground elevation most of
the time, but here is at least one situation where it doesn't. YASim
doesn't handle this at all (but Andy's the new kid so we can cut him
some slack.) :-)
Uh, stupid question: where do I stick
Andy Ross writes:
Curtis L. Olson wrote:
JSBSim properly handles updating the runway/ground elevation most of
the time, but here is at least one situation where it doesn't. YASim
doesn't handle this at all (but Andy's the new kid so we can cut him
some slack.) :-)
Uh, stupid
Curtis L. Olson wrote:
Andy Ross wrote:
Uh, stupid question: where do I stick the number? I can't imagine
this is difficult to fix.
Should be a breeze.
Essentially you are assuming that the runway elevation field in the
FGInterface structure is getting updated externally by
I think that does the trick, thank!
Curt.
Andy Ross writes:
Curtis L. Olson wrote:
Andy Ross wrote:
Uh, stupid question: where do I stick the number? I can't imagine
this is difficult to fix.
Should be a breeze.
Essentially you are assuming that the runway elevation
Tony Peden wrote:
Well, I wasn't saying this was the cuase of the
problem, just *a*
solution. I figured there might be a counter
somwhere which decreses
GearPos by a certain amount, but the check didn't
catch it being close
to 0.0
Therefore it would en up in an endless loop or
something.
On Thu, 2002-02-14 at 09:09, Alex Perry wrote:
The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO.
Immediate crash. It's a long way to commute, could we fix that sometime?
I've sent a fix off to Curt for this.
___
On Fri, 2002-02-15 at 12:12, Erik Hofman wrote:
Erik Hofman wrote:
Tony Peden wrote:
.
It's possible. Do you notice any problem with the
flaps? (it's the same code:
FDM/JSBSim/filtersjb/FGKinemat.[h|cpp])
Well, not noticably. But the problem is there.
When uncommenting line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello list,
I've been playing around with the telnet interface a bit, and
have made a little trim-aid for us poor keyboard-users. More of
that below.
I also discovered some minor issues with fgfs:
* It is not possible to have more then 1 active
Martin van Beilen wrote:
Unfortunately the script won't work very well with JSBSim. JSBSim's
aileron trim is so insensitive that it can't even compensate for one
notch of rudder. (IANAP, so I don't know how realistic that is.)
YASim's aileron trim seems to behave like a secondary aileron
* [EMAIL PROTECTED] (Andy Ross) [2002.02.15 18:03]:
And the script is a marvelous hack, by the way. But... sh and awk?
Goodness gracious, learn some perl, man! :)
Don't forget netcat! :-) Yes, definately gets bonus 'hack points'.
--
Cameron Moore
[ Why is the word dictionary in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Feb 15, 2002 at 03:59:04PM -0800, Andy Ross wrote:
That's exactly how trim works in YASim -- the existing aircraft files
simply add trim and stick together and clamp to -1:1. In principle,
this is tunable per-aircraft, so that full trim
Then again, if I were _really_ hacking, I'd write it in
Postscript, run it on a network printer and use its bright/dark
control to set the roll. Perhaps I could even get the ATIS text
to scroll on its display. :)
Now *that's* funny.
:-)
Jon
24 matches
Mail list logo
