Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 15:13, Jim Wilson wrote: Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. Hmm, but virtually every FDM calls FGInterface::common_init() in init(). And this one copies the initial values of the aircraft into the FDM. So if this data is screwed up at call of init(), this screwed up data ends in the FDM. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. Ok, I can find this is_suspended() call in the first line of JSBSim::update(double). So I guess that this is_suspended() call should return true as long as the remaining subsystems are not set up? Or how is this interface supposed to know when it can start computing physics? Ok, I have prepared all set_* calls in the JSBsim FGInterface with a cout function name function arguments to see what is different when the FDM is initialized at the first time and at reset time. This is the output at flightgear start: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() virtual void FGJSBsim::update(double) is_suspended() 0 What we can see here is that there is no problem with agl or altitude below -9990ft. Also the is_suspended() call is never true. This are the JSBSim FGInterface function entries when I press the reset menu entry: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Climb_Rate(double) roc = -0.00421123 virtual void FGJSBsim::set_Gamma_vert_rad(double) gamma = -0.00082482 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() The set_Climb_Rate, set_Gamma_vert_rad calls are new here. And I think that this is the problem. The rest looks identical. Ok, when I see this, I think that we should eliminate the duplicate calls. And I still think that it is not the job of a specific FDM to check for an error condition of the tile loader, even if this is not the error at the moment. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? I get more and more confused with this interface. JSBSim, copies almost all initial conditions at the init() call and updates these values with the ones superseeded by FGInterface::set_* calls. At the first entry to update(double) it checks if some initial conditions have changed and trims if required. So how is this interface class supposed to work? What could a FDM expect to be set up at which call to an interface function? And where is this documented :-) ? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Mathias Fröhlich said: On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Friday 02 Apr 2004 2:23 pm, David Culp wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave The reset function I (hardly ever) use is bound to Shift-Esc in data/keyboard.xml: key n=27 nameESC/name descPrompt and quit FlightGear./desc binding commanddialog-show/command dialog-nameexit/dialog-name /binding mod-shift descReset FlightGear./desc binding commandold-reinit-dialog/command /binding /mod-shift /key 'Location | Position Aircraft (on ground)' didn't work for me at a number of Californian airfields with the C172-3d - an external view shows the plane tumbling around the sky like an empty plastic bag! I also tried to position in air, which was more successful, except I wasn't quite ready for the magneto switch being in the OFF position :¬) Good job I didn't have to get out and swing the propeller, eh? Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the
problem only affects a couple JSBSim aircraft...the c172 (all of them) and the
737. Everything else seems to trim fine.
The issue appears to be due to a difference between how the FDM is initialized
on startup and how it is initialized on restart. On startup the FDM
initialization is delayed until a tile is loaded for the startup location,
giving an accurate ground elevation value (test for gound_elev -9990). This
test is not possible during the reinit phase, because we're only passing
through the reinitialize routine once.
The more I look at the workarounds we have been accumulating for making
flightgear initialize and reinitialize the more I realize that we may be
frequently taking the wrong approach to solving such issues. We are failing
to build self-sufficient and self-protecting subsystems.
Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or
the ground_elelvation is -9990, would it be possible for JSBSim to not
ground trim and instead go for a coffee or freeze or whatever it needs to do
while the scenery system gets wound up?
In other words, rather than try and find another bandaid, what I would like
to do is remove the elevation test from following code in main.cxx and let the
fdm take care of itself:
if ( !cur_fdm_state-get_inited()
globals-get_scenery()-get_cur_elev() -9990 )
{
SG_LOG(SG_FLIGHT,SG_INFO, Finally initializing fdm);
cur_fdm_state-init();
if ( cur_fdm_state-get_bound() ) {
cur_fdm_state-unbind();
}
cur_fdm_state-bind();
}
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the
problem only affects a couple JSBSim aircraft...the c172 (all of
them) and the 737. Everything else seems to trim fine.
I wonder why this is only an issue with these aircraft ???
Which is why I'm calling this a JSBSim bug. If the altitude is -9990
and/or
the ground_elelvation is -9990, would it be possible for JSBSim to not
ground trim and instead go for a coffee or freeze or whatever it
needs to do while the scenery system gets wound up?
So, which one is the key? What is altitude in the above context? I assume
you are not talking about aircraft altitude ... ? What kind of re-init is
desired or expected?
In other words, rather than try and find another bandaid, what
I would like to do is remove the elevation test from following code in
main.cxx and let the fdm take care of itself:
if ( !cur_fdm_state-get_inited()
globals-get_scenery()-get_cur_elev() -9990 )
{
SG_LOG(SG_FLIGHT,SG_INFO, Finally initializing fdm);
cur_fdm_state-init();
if ( cur_fdm_state-get_bound() ) {
cur_fdm_state-unbind();
}
cur_fdm_state-bind();
}
I'm all for doing it right. I'm sure we can change this to make any
proposal work. I'm a little rusty on this stuff, though, so the more input
you give me the better.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim initialization bug
Jon Berndt said:
Earlier we had a report of a reset issue on the list. It appears that the
problem only affects a couple JSBSim aircraft...the c172 (all of
them) and the 737. Everything else seems to trim fine.
I wonder why this is only an issue with these aircraft ???
Which is why I'm calling this a JSBSim bug. If the altitude is -9990
and/or
the ground_elelvation is -9990, would it be possible for JSBSim to not
ground trim and instead go for a coffee or freeze or whatever it
needs to do while the scenery system gets wound up?
So, which one is the key? What is altitude in the above context? I assume
you are not talking about aircraft altitude ... ? What kind of re-init is
desired or expected?
In other words, rather than try and find another bandaid, what
I would like to do is remove the elevation test from following code in
main.cxx and let the fdm take care of itself:
if ( !cur_fdm_state-get_inited()
globals-get_scenery()-get_cur_elev() -9990 )
{
SG_LOG(SG_FLIGHT,SG_INFO, Finally initializing fdm);
cur_fdm_state-init();
if ( cur_fdm_state-get_bound() ) {
cur_fdm_state-unbind();
}
cur_fdm_state-bind();
}
I'm all for doing it right. I'm sure we can change this to make any
proposal work. I'm a little rusty on this stuff, though, so the more input
you give me the better.
It's probably just ground_elev, although I notice the altitude is - on the
first pass. The init and reinit is fine, what is broken is how a bogus value
(ground_evel of -9990) is handled. The ground elevation test in the
scenery code returns - when the current scenery tile isn't loaded yet.
I'm going to try testing the ground_elev in the update() call in JSBSim.cxx,
but there are several places where elevation is looked at and it isn't clear
to me where (or if) trouble might occur. Probably just checking before
calling dotrim() will fix this particular issue. I would just ask the
question, if we knew that the elevation (and/or altitude?) values could be
bogus, what would we do differently? The other question I guess is how we
define bogus. Is -9990 for any value sufficient?
As far as why those two aircraft not the others... I was hoping someone else
might know :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
