Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 22 Feb 2002, Michael Basler wrote: > This is the released Windows binary 0.7.9 (which shouldn't matter, though) > and the default Cessna 172. Also on the windows binary I noticed that there's an offset error when trying to select from the menu system - you have to aim 1 option *above* the one you actually want to select. -- Jon StockillPublic Key: C6BD585D [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
--- Martin Dressler <[EMAIL PROTECTED]> wrote: > On Sat 23. February 2002 01:06, you wrote: > > The flightgear side really only knows the current > ground elevation for > > a specific lon/lat. FlightGear has no way to know > the dimensions of a > > specific aircraft or the relative placement of the > gear. It would > > seem like the best thing FlightGear can do is > provide the elevation of > > the ground for the starting lon/lat, and then it > should be up to the > > FDM to do the rest. > > BTW How you can get altitude of specific lat,lon > position, please? > > What about scheme, when FDM or other SubSystem store > lat,lon position > structures on some heap and after frame render get > it back with filled > altitude. The scheme used to pass the data back and forth is not the problem. It's farther upstream than that. > > > The FDM passes back the location of the aircraft's > CG, and this > > combined with knowledge of the aircraft > orientation and pilot view > > offset relative to the CG allows FlightGear to > properly render the > > scene. > > > > I don't know the details of how it works know, but > it seems like the > > FDM would need to find a suitable starting point > for the CG given the > > information FlightGear can provide (which is the > ground elevation.) > > > > This is a tricky area though so if there's > something I'm missing feel > > free to point it out. :-) > > > > Curt. > > Madr > > -- > Martin Dressler > > e-mail: [EMAIL PROTECTED] > http://www.musicabona.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Sat 23. February 2002 01:06, you wrote: > The flightgear side really only knows the current ground elevation for > a specific lon/lat. FlightGear has no way to know the dimensions of a > specific aircraft or the relative placement of the gear. It would > seem like the best thing FlightGear can do is provide the elevation of > the ground for the starting lon/lat, and then it should be up to the > FDM to do the rest. BTW How you can get altitude of specific lat,lon position, please? What about scheme, when FDM or other SubSystem store lat,lon position structures on some heap and after frame render get it back with filled altitude. > The FDM passes back the location of the aircraft's CG, and this > combined with knowledge of the aircraft orientation and pilot view > offset relative to the CG allows FlightGear to properly render the > scene. > > I don't know the details of how it works know, but it seems like the > FDM would need to find a suitable starting point for the CG given the > information FlightGear can provide (which is the ground elevation.) > > This is a tricky area though so if there's something I'm missing feel > free to point it out. :-) > > Curt. Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On 22 Feb 2002 16:56:58 -0800, Tony Peden <[EMAIL PROTECTED]> wrote in message <1014425818.3606.46.camel@raptor>: > On Fri, 2002-02-22 at 16:23, Andy Ross wrote: > > Tony Peden writes: > > What YASim does is just lift the plane up until the (fully extended) > > gear are off the ground, and drop it. The plane bounces nicely to a > > stable resting orientation. > > JSBSim starts out doing a similar thing, but then goes on to adjust > height, pitch angle,and roll angle until the aircraft is in > equilibrium. At the moment, I think it's just not doing it with the > right number at CL77. I don't yet know why that is. ..does the sim planes free-fall onto the runway, or can they "be lowered onto the runway/parkingplace/platform/etc" from a "code steel rope sling" of some sort, slowly enough? ..high enough free-falls triggers mishap code, right? ..just prelim fix ideas, the "correct" way I guess is get altitudes etc right... Still learning... -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 11:25, Curtis L. Olson wrote: > I believe I have found/fixed the initialization order problem. > Flightgear has a concept of an 'absolute' view position in cartesian > coordinates where (0,0,0) is the center of the Earth; and a 'relative' > view position where (0,0,0) is the center of the current tile. (This > is to work around limitations in 'float' precision in OpenGL.) > > To get back a valid terrain intersection, you need both the absolute > and relative view positions to be set correctly. But, you can't set > the relative view position until after you know the center point of > the current tile. > > So, in some starting locations by pure chance, we were getting a > scenery intersection for a wrong location because the relative view > position hadn't been set correctly yet. > > The next time through the loop the relative view position was correct > and the scenery intersection point was the also correct. > > The problem was that the FDM initialization was handed a wrong > starting altitude which could understandably confuse the FDM. > > I have commited fixes to CVS for this problem. > > > Tony <- > > Even after these fixes though, JSBSim flips upside down and flags a > 'mishap'[1] at CL77. > > There is something about this airport that still confuses the JSBSim > initialization code. Perhaps it is the steep slope of the runway? > > [1] note the careful use of wording to avoid confusing with an > application or computer crash. :-) OK, this is what I found at CL77. >From the console log, the terrain altitude JSBSim gets at init time is 1924.47 ft: Starting and initializing JSBsim Start common FDM init ...initializing position... FGJSBsim::set_Longitude: -2.13148 FGJSBsim::set_Latitude: 0.646962 cur alt (ft) = 0 FGJSBsim::set_Altitude: 1924.47 lat (deg) = 37.0682 Terrain altitude: 1924.47 ^^^ ...initializing ground elevation to 1924.47ft... ...initializing sea-level radius... lat = 37.0682 alt = 1924.47 ...initializing velocities... FGJSBsim::set_V_calibrated_kts: 0 ...initializing Euler angles... FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.51524 End common FDM init However, putting an output statement just before the ground trim ( in the first call to FGInterface::update() ) is run shows that it has changed: Loading tile /home/tony/FlightGear/Scenery/w130n30/w123n37/942018 token = OBJECT_BASE name = 942018.btg Ready to trim, terrain altitude is: 1928.41 ^^ Ground Trim Initial Theta: 0.9126 Trim successful JSBSim State Trim complete I put in code to update JSBSim's terrain altitude right before the trim and it does improve matters, but not 100% as the final terrain altitude doesn't always seem to be available at that time. As noted yesterday, setting --altitude works around the problem. What seems to be more interesting about that is that JSBSim gets initialized with the final terrain altitude very reliably. Might be a clue to what's really wrong. I didn't look at LOWI, though I suspect the problem there is similar. > > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > > Cameron Moore writes: > > * [EMAIL PROTECTED] (Curt Olson) [2002.02.22 12:26]: > > > Jim Wilson writes: > > > > Hope they disconnected the usb Flamethrower first :-) I'm getting the same > > > > thing with CL77. Some screwy looking airstrip. There still seems to be some > > > > problems with altitude between fg and jsbsim. A workaround is to add a > > > > --alititude=(runway elevation) to the command line. > > > > > > > > This perhaps is a naive question, but why aren't we kicking in the FDM after > > > > the plane is on the runway during initialization? > > > > > > We are actually doing this. We don't initialize the FDM until the > > > scenery subsystem is reporting a valid ground elevation. However, for > > > some starting locations it appears that the initial reported elevation > > > is incorrect the first frame and then updated to the correct elevation > > > the second frame. > > > > This may be totally unrelated, but ... The FPE issue I posted about the > > other day is triggered when the tile manager is initialized. Could > > it be that tile manager is getting a bogus starting point due to this > > FPE bug, and that bogus value is making it's way to the FDM's? > > -- > > Cameron Moore > > / If a person with multiple personalities threatens \ > > \ suicide, is that considered a hostage situation? / > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > ___ > Flightgear-devel mailing list > [EMAIL PRO
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 20:52, Curtis L. Olson wrote: > > > This may or may not be related but when I start up at an airport for > > which i have no scenery, the elevation is below 0. At EHAM it is > > -17 ft as shown in /position/altitude-ft. > > Actually, when an ocean tile is automatically generated, we use really > big triangles (i.e. two triangle to cover the whole tile.) If the > elevation is 0 at the corners, the surface of the tile forms a sort of > 3d square 'secant' so the elevation within the ocean tile will be < > 0. -17 sounds reasonable for an interior position. I don't suppose this is relevant (since it was already pointed out that true airport elevation is not used), but EHAM (Amsterdam schipol) really is below sea level; there have been some notable problems with this in FS200X. And seventeen feet sounds plausible (I have seen 11ft to 15ft in different places) It's a feature, not a bug :-) Having said that, I just took off from their (with scenery) no trouble. H&H James msg02961/pgp0.pgp Description: PGP signature
AW: [Flightgear-devel] Problem report on release 0.7.9
Hi, For what it's worth: I made an extended test of several German/Austrian airports after installing the most recent CVS version including Curt's patch. These are the results: Working (no "mishap"): EDDM LSZR EDDS EDDN LOWI LIBP LSZS LSPM These require scenery packages e000n40 + e010n40. All these work fine. They even include some quite spectacular airports like LSZS, LSPM with considerably tilted runways. On the other hand, the couple CL77 LOWI still does not work by producing a "mishap". There must be something special about them. At least I know LOWI situated in a valley does not have a strongly tilted runway. This is even more a pity as LOWI is quite a famous and spectacular approach (I once had a chance to do it in a "real" simulator :-). Finally: Dave, your textured C172 is highly welcome. While I fortunately did not have to see it from the inside most of the time, I hated that glider. Sincerely, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 16:23, Andy Ross wrote: > Tony Peden writes: > > Just for the record, what's most likely happening here is that since > > JSBSim senses that the gear are underground on the first update(), the > > gear code calculate a reaction force based on how far underground they > > are. > > One thing you might try is clamping the gear force to that produced by > fully compressed gear. That way, you avoid the absurd forces produced > by springs compressed by 100x their real-world size. It doesn't fix > the underground problem, but it might help keep the results from > exploding. True, it would help. But what do we do then? I'm not ready to do anything approaching real structural modeling. > > Curtis L. Olson wrote: > > I don't know the details of how it works know, but it seems like the > > FDM would need to find a suitable starting point for the CG given the > > information FlightGear can provide (which is the ground elevation.) > > What YASim does is just lift the plane up until the (fully extended) > gear are off the ground, and drop it. The plane bounces nicely to a > stable resting orientation. JSBSim starts out doing a similar thing, but then goes on to adjust height, pitch angle,and roll angle until the aircraft is in equilibrium. At the moment, I think it's just not doing it with the right number at CL77. I don't yet know why that is. > > One thing to consider would be exporting the tile geometry to the FDMs > in some way. Assuming a flat ground plane is fine for runway > environments, of course, but curved surfaces won't work that way. One > way to do it would be for the FDM to provide a line description > (direction of gear compression), which the scenery would convert into > an intersection point and a normal vector for the ground at that > point. > > In particular, ski jumps have curvature of the order of the inter-gear > distance, and can't be approximated with any plane at all. Of course, > these are very special purpose, and might best be handled with a > special case inside the gear code... > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
Tony Peden writes: > Just for the record, what's most likely happening here is that since > JSBSim senses that the gear are underground on the first update(), the > gear code calculate a reaction force based on how far underground they > are. One thing you might try is clamping the gear force to that produced by fully compressed gear. That way, you avoid the absurd forces produced by springs compressed by 100x their real-world size. It doesn't fix the underground problem, but it might help keep the results from exploding. Curtis L. Olson wrote: > I don't know the details of how it works know, but it seems like the > FDM would need to find a suitable starting point for the CG given the > information FlightGear can provide (which is the ground elevation.) What YASim does is just lift the plane up until the (fully extended) gear are off the ground, and drop it. The plane bounces nicely to a stable resting orientation. One thing to consider would be exporting the tile geometry to the FDMs in some way. Assuming a flat ground plane is fine for runway environments, of course, but curved surfaces won't work that way. One way to do it would be for the FDM to provide a line description (direction of gear compression), which the scenery would convert into an intersection point and a normal vector for the ground at that point. In particular, ski jumps have curvature of the order of the inter-gear distance, and can't be approximated with any plane at all. Of course, these are very special purpose, and might best be handled with a special case inside the gear code... Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
Tony Peden writes: > Just for the record, what's most likely happening here is that since > JSBSim senses that the gear are underground on the first update(), the > gear code calculate a reaction force based on how far underground they > are. That reaction force pushes the aircraft up, often times gaining > enough momentum in the process to leave the ground. Then the result is > pretty predictable, the aircraft experiences an accident. (it will > almost certainly involve a complete hull loss, therefore it's an > accident) > > AFAIK, There are currently no limits on how far the gear can be > compressed, so the reaction forces can get very large. The flightgear side really only knows the current ground elevation for a specific lon/lat. FlightGear has no way to know the dimensions of a specific aircraft or the relative placement of the gear. It would seem like the best thing FlightGear can do is provide the elevation of the ground for the starting lon/lat, and then it should be up to the FDM to do the rest. The FDM passes back the location of the aircraft's CG, and this combined with knowledge of the aircraft orientation and pilot view offset relative to the CG allows FlightGear to properly render the scene. I don't know the details of how it works know, but it seems like the FDM would need to find a suitable starting point for the CG given the information FlightGear can provide (which is the ground elevation.) This is a tricky area though so if there's something I'm missing feel free to point it out. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 11:25, Curtis L. Olson wrote: > > > Tony <- > > Even after these fixes though, JSBSim flips upside down and flags a > 'mishap'[1] at CL77. OK, I'll take a look. > > There is something about this airport that still confuses the JSBSim > initialization code. Perhaps it is the steep slope of the runway? AFAIK, JSBSim doesn't have any concept of runway slope at this point but as you say, anything is possible. > > [1] note the careful use of wording to avoid confusing with an > application or computer crash. :-) Duly noted Just for the record, what's most likely happening here is that since JSBSim senses that the gear are underground on the first update(), the gear code calculate a reaction force based on how far underground they are. That reaction force pushes the aircraft up, often times gaining enough momentum in the process to leave the ground. Then the result is pretty predictable, the aircraft experiences an accident. (it will almost certainly involve a complete hull loss, therefore it's an accident) AFAIK, There are currently no limits on how far the gear can be compressed, so the reaction forces can get very large. > > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > > Cameron Moore writes: > > * [EMAIL PROTECTED] (Curt Olson) [2002.02.22 12:26]: > > > Jim Wilson writes: > > > > Hope they disconnected the usb Flamethrower first :-) I'm getting the same > > > > thing with CL77. Some screwy looking airstrip. There still seems to be some > > > > problems with altitude between fg and jsbsim. A workaround is to add a > > > > --alititude=(runway elevation) to the command line. > > > > > > > > This perhaps is a naive question, but why aren't we kicking in the FDM after > > > > the plane is on the runway during initialization? > > > > > > We are actually doing this. We don't initialize the FDM until the > > > scenery subsystem is reporting a valid ground elevation. However, for > > > some starting locations it appears that the initial reported elevation > > > is incorrect the first frame and then updated to the correct elevation > > > the second frame. > > > > This may be totally unrelated, but ... The FPE issue I posted about the > > other day is triggered when the tile manager is initialized. Could > > it be that tile manager is getting a bogus starting point due to this > > FPE bug, and that bogus value is making it's way to the FDM's? > > -- > > Cameron Moore > > / If a person with multiple personalities threatens \ > > \ suicide, is that considered a hostage situation? / > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Jim Wilson writes: > > > If you set --altitude=1933 when starting at CL77 the mishap does not > > occur. > > JSBSim is getting fed a consistant starting ground elevation now with > the latest CVS changes. Yes I updated before replying, this works with the latest changes. Try setting --altitude=1933 (probably doesn't prove anything). I noticed that we're passing it 1924 (or at least thats what JSBsim is initializing at first pass). > > And I guess I'm wondering still if it is possible to set the plane > > on that tile before reporting position to FDM's so that it still > > works even if there is a data problem. > > This is what we do. The tile is loaded and a valid ground elevation > is determined before the FDM init() routine is called. > Ok sorry for the stupid q's :-) > > This may or may not be related but when I start up at an airport for > > which i have no scenery, the elevation is below 0. At EHAM it is > > -17 ft as shown in /position/altitude-ft. > > Actually, when an ocean tile is automatically generated, we use really > big triangles (i.e. two triangle to cover the whole tile.) If the > elevation is 0 at the corners, the surface of the tile forms a sort of > 3d square 'secant' so the elevation within the ocean tile will be < > 0. -17 sounds reasonable for an interior position. > Ah, ok ...makes sense. Thanks for the explanation. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
Jim Wilson writes: > Yes actually all I've seen on this particular issue is a "mishap" > the software doesn't bail out or crash which is what it did in some > cases before Tony's fix. > > The airport database shows 2020ft as the elevation (which matches > this: http://www.airnav.com/airport/CL77 ). The tile for the runway > that is actually at 1933ft. The elevation of the FlightGear airports are set by the DEM data for that area. It would be nice to feed in actual airport elevations, but that is a more complicated process and would require some adaptive adjusting of surrounding elevation points to smoothly blend the airport into the surrounding terrain. I haven't sat down and thought about how that might be implimented. > If you set --altitude=1933 when starting at CL77 the mishap does not > occur. JSBSim is getting fed a consistant starting ground elevation now with the latest CVS changes. > Could this just be a problem with scenery data? I'm going to say 'nope' not possible with the disclaimer that probably anything is possible. However, all the evidence I've seen so far points to a problem with how JSBSim intializes itself on the ground. My guess at the moment is that perhaps there is a large enough slope that the ground trim is failing? Note that YASim now initializes itself just fine at all these airports for which JSBSim is failing. That doesn't necessarily prove anything I know, but I think the ball is now in Tony/Jon's court to either fix the problem or show some evidence why the problem lies elsewhere. > And I guess I'm wondering still if it is possible to set the plane > on that tile before reporting position to FDM's so that it still > works even if there is a data problem. This is what we do. The tile is loaded and a valid ground elevation is determined before the FDM init() routine is called. > This may or may not be related but when I start up at an airport for > which i have no scenery, the elevation is below 0. At EHAM it is > -17 ft as shown in /position/altitude-ft. Actually, when an ocean tile is automatically generated, we use really big triangles (i.e. two triangle to cover the whole tile.) If the elevation is 0 at the corners, the surface of the tile forms a sort of 3d square 'secant' so the elevation within the ocean tile will be < 0. -17 sounds reasonable for an interior position. By secant I mean something analogous to line CD in this diagram: http://www.ischoolzone.com/review/Courses%5CMasterMath%5CMK19612.gif Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Even after these fixes though, JSBSim flips upside down and flags a > 'mishap'[1] at CL77. > > There is something about this airport that still confuses the JSBSim > initialization code. Perhaps it is the steep slope of the runway? > > [1] note the careful use of wording to avoid confusing with an > application or computer crash. :-) > Yes actually all I've seen on this particular issue is a "mishap" the software doesn't bail out or crash which is what it did in some cases before Tony's fix. The airport database shows 2020ft as the elevation (which matches this: http://www.airnav.com/airport/CL77 ). The tile for the runway that is actually at 1933ft. If you set --altitude=1933 when starting at CL77 the mishap does not occur. Could this just be a problem with scenery data? And I guess I'm wondering still if it is possible to set the plane on that tile before reporting position to FDM's so that it still works even if there is a data problem. This may or may not be related but when I start up at an airport for which i have no scenery, the elevation is below 0. At EHAM it is -17 ft as shown in /position/altitude-ft. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
Tony Peden <[EMAIL PROTECTED]> said: > > Did my 'fix' to fgFDMForceAltitude() get in to the > 0.7.9 release? > Not sure but I think it did. I'm testing with cvs (as of yesterday or so). Anything I can do to help? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
I believe I have found/fixed the initialization order problem. Flightgear has a concept of an 'absolute' view position in cartesian coordinates where (0,0,0) is the center of the Earth; and a 'relative' view position where (0,0,0) is the center of the current tile. (This is to work around limitations in 'float' precision in OpenGL.) To get back a valid terrain intersection, you need both the absolute and relative view positions to be set correctly. But, you can't set the relative view position until after you know the center point of the current tile. So, in some starting locations by pure chance, we were getting a scenery intersection for a wrong location because the relative view position hadn't been set correctly yet. The next time through the loop the relative view position was correct and the scenery intersection point was the also correct. The problem was that the FDM initialization was handed a wrong starting altitude which could understandably confuse the FDM. I have commited fixes to CVS for this problem. > Tony <- Even after these fixes though, JSBSim flips upside down and flags a 'mishap'[1] at CL77. There is something about this airport that still confuses the JSBSim initialization code. Perhaps it is the steep slope of the runway? [1] note the careful use of wording to avoid confusing with an application or computer crash. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org Cameron Moore writes: > * [EMAIL PROTECTED] (Curt Olson) [2002.02.22 12:26]: > > Jim Wilson writes: > > > Hope they disconnected the usb Flamethrower first :-) I'm getting the same > > > thing with CL77. Some screwy looking airstrip. There still seems to be some > > > problems with altitude between fg and jsbsim. A workaround is to add a > > > --alititude=(runway elevation) to the command line. > > > > > > This perhaps is a naive question, but why aren't we kicking in the FDM after > > > the plane is on the runway during initialization? > > > > We are actually doing this. We don't initialize the FDM until the > > scenery subsystem is reporting a valid ground elevation. However, for > > some starting locations it appears that the initial reported elevation > > is incorrect the first frame and then updated to the correct elevation > > the second frame. > > This may be totally unrelated, but ... The FPE issue I posted about the > other day is triggered when the tile manager is initialized. Could > it be that tile manager is getting a bogus starting point due to this > FPE bug, and that bogus value is making it's way to the FDM's? > -- > Cameron Moore > / If a person with multiple personalities threatens \ > \ suicide, is that considered a hostage situation? / > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
* [EMAIL PROTECTED] (Curt Olson) [2002.02.22 12:26]: > Jim Wilson writes: > > Hope they disconnected the usb Flamethrower first :-) I'm getting the same > > thing with CL77. Some screwy looking airstrip. There still seems to be some > > problems with altitude between fg and jsbsim. A workaround is to add a > > --alititude=(runway elevation) to the command line. > > > > This perhaps is a naive question, but why aren't we kicking in the FDM after > > the plane is on the runway during initialization? > > We are actually doing this. We don't initialize the FDM until the > scenery subsystem is reporting a valid ground elevation. However, for > some starting locations it appears that the initial reported elevation > is incorrect the first frame and then updated to the correct elevation > the second frame. This may be totally unrelated, but ... The FPE issue I posted about the other day is triggered when the tile manager is initialized. Could it be that tile manager is getting a bogus starting point due to this FPE bug, and that bogus value is making it's way to the FDM's? -- Cameron Moore / If a person with multiple personalities threatens \ \ suicide, is that considered a hostage situation? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
Tony Peden writes: > > --- "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Jim Wilson writes: > > > Hope they disconnected the usb Flamethrower first > > :-) I'm getting the same > > > thing with CL77. Some screwy looking airstrip. > > There still seems to be some > > > problems with altitude between fg and jsbsim. A > > workaround is to add a > > > --alititude=(runway elevation) to the command > > line. > > > > > > This perhaps is a naive question, but why aren't > > we kicking in the FDM after > > > the plane is on the runway during initialization? > > > > We are actually doing this. We don't initialize the > > FDM until the > > scenery subsystem is reporting a valid ground > > elevation. However, for > > some starting locations it appears that the initial > > reported elevation > > is incorrect the first frame and then updated to the > > correct elevation > > the second frame. > > Did my 'fix' to fgFDMForceAltitude() get in to the > 0.7.9 release? I'm working from CVS and I am still seeing this at CL77. However, I appear to have identified a flightgear bug which is initialization order dependent ... i.e. the first scenery elevation returned can some times be for the wrong location, giving the wrong altitude. Subsequent scenery elevations are correct because the various position values are all synced up by then. > > > It seems like there's a > > > lot of trouble trying to get an FDM synced up with > > scenery/airport data during > > > startup. Why is it that flightgear doesn't just > > put the plane where it goes > > > and dictate the coordinates at startup (or reset) > > and let the flight model > > > (re-)initialize with those values? It's pretty > > obvious that when there's a > > > gross discrepency in elevation data (as with CL77) > > the FDM has kicked in and > > > the plane is stalling and drifting down to the > > ground...hence the > > > "crash". > > > > Right, but we are already doing what you describe, > > the problem is that > > something isn't working quite right in all > > situations. > > > > Regards, > > > > Curt. > > -- > > Curtis Olson IVLab / HumanFIRST Program > > FlightGear Project > > Twin Cities[EMAIL PROTECTED] > > [EMAIL PROTECTED] > > Minnesota http://www.menet.umn.edu/~curt > > http://www.flightgear.org > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > > > __ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
--- "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > Jim Wilson writes: > > Hope they disconnected the usb Flamethrower first > :-) I'm getting the same > > thing with CL77. Some screwy looking airstrip. > There still seems to be some > > problems with altitude between fg and jsbsim. A > workaround is to add a > > --alititude=(runway elevation) to the command > line. > > > > This perhaps is a naive question, but why aren't > we kicking in the FDM after > > the plane is on the runway during initialization? > > We are actually doing this. We don't initialize the > FDM until the > scenery subsystem is reporting a valid ground > elevation. However, for > some starting locations it appears that the initial > reported elevation > is incorrect the first frame and then updated to the > correct elevation > the second frame. Did my 'fix' to fgFDMForceAltitude() get in to the 0.7.9 release? > > > It seems like there's a > > lot of trouble trying to get an FDM synced up with > scenery/airport data during > > startup. Why is it that flightgear doesn't just > put the plane where it goes > > and dictate the coordinates at startup (or reset) > and let the flight model > > (re-)initialize with those values? It's pretty > obvious that when there's a > > gross discrepency in elevation data (as with CL77) > the FDM has kicked in and > > the plane is stalling and drifting down to the > ground...hence the > > "crash". > > Right, but we are already doing what you describe, > the problem is that > something isn't working quite right in all > situations. > > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program > FlightGear Project > Twin Cities[EMAIL PROTECTED] > [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt > http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
Jim Wilson writes: > Hope they disconnected the usb Flamethrower first :-) I'm getting the same > thing with CL77. Some screwy looking airstrip. There still seems to be some > problems with altitude between fg and jsbsim. A workaround is to add a > --alititude=(runway elevation) to the command line. > > This perhaps is a naive question, but why aren't we kicking in the FDM after > the plane is on the runway during initialization? We are actually doing this. We don't initialize the FDM until the scenery subsystem is reporting a valid ground elevation. However, for some starting locations it appears that the initial reported elevation is incorrect the first frame and then updated to the correct elevation the second frame. > It seems like there's a > lot of trouble trying to get an FDM synced up with scenery/airport data during > startup. Why is it that flightgear doesn't just put the plane where it goes > and dictate the coordinates at startup (or reset) and let the flight model > (re-)initialize with those values? It's pretty obvious that when there's a > gross discrepency in elevation data (as with CL77) the FDM has kicked in and > the plane is stalling and drifting down to the ground...hence the > "crash". Right, but we are already doing what you describe, the problem is that something isn't working quite right in all situations. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
"BERNDT, JON S. (JON) (JSC-EX) (LM)" <[EMAIL PROTECTED]> said: > > From: Michael Basler [mailto:[EMAIL PROTECTED]] > > > > Hi, > > > > I just received a problem report from a German user on the > > released version > > 0.7.9 which I - unfortunately - was able to confirm in part. > > > > 1. Start at CL77 Santa Cruz leads to an immediate crash. > > > > 2. He reported a crash at Munich EDDM at start (e010n40 > > installed) which I could not confirm. > > > > 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. > > OK. Has the NTSB been called to the scene[s], yet? > > :-P > > Jon > Hope they disconnected the usb Flamethrower first :-) I'm getting the same thing with CL77. Some screwy looking airstrip. There still seems to be some problems with altitude between fg and jsbsim. A workaround is to add a --alititude=(runway elevation) to the command line. This perhaps is a naive question, but why aren't we kicking in the FDM after the plane is on the runway during initialization? It seems like there's a lot of trouble trying to get an FDM synced up with scenery/airport data during startup. Why is it that flightgear doesn't just put the plane where it goes and dictate the coordinates at startup (or reset) and let the flight model (re-)initialize with those values? It's pretty obvious that when there's a gross discrepency in elevation data (as with CL77) the FDM has kicked in and the plane is stalling and drifting down to the ground...hence the "crash". I guess a side question is to this is why don't the FDM's freeze the lat+long+alt when the parking brake is on and the ground speed is < 1? And keep it frozen until the brake is released. Seems like that'd be an easy way to stop the creeping that some people have complained about. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
> > OK. Has the NTSB been called to the scene[s], yet? > > They are not responsible for accidents on European territory ;-) I don't think they are *responsible* for _crashes_ anywhere! :-P Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
>> 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. > OK. Has the NTSB been called to the scene[s], yet? They are not responsible for accidents on European territory ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] Problem report on release 0.7.9
John, ... > > 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. > > OK. Has the NTSB been called to the scene[s], yet? At least in Germany they do not handle software-related crashes, though... To make it clear: The program starts with a crash already. Reset results in the same situation. So, can anyone confirm these or is it just me or Martin or that other guy who asked...? BTW, according to him there are more of these dangerous places. In case we'll be proven right I foresee more to follow in complaining. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem report on release 0.7.9
> From: Michael Basler [mailto:[EMAIL PROTECTED]] > > Hi, > > I just received a problem report from a German user on the > released version > 0.7.9 which I - unfortunately - was able to confirm in part. > > 1. Start at CL77 Santa Cruz leads to an immediate crash. > > 2. He reported a crash at Munich EDDM at start (e010n40 > installed) which I could not confirm. > > 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. OK. Has the NTSB been called to the scene[s], yet? :-P Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem report on release 0.7.9
Hi, I just received a problem report from a German user on the released version 0.7.9 which I - unfortunately - was able to confirm in part. 1. Start at CL77 Santa Cruz leads to an immediate crash. 2. He reported a crash at Munich EDDM at start (e010n40 installed) which I could not confirm. 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. BTW, starting from Munich I was not unable to see the alps. I did not fly for long, but I know they can be seen in MSFS shortly after the start (given proper visibility settings). This is the released Windows binary 0.7.9 (which shouldn't matter, though) and the default Cessna 172. So, something seems to go wrong here. I recall a discussion on crash issues on airports other than KSFO on the list, but thought that would have been solved. I talked to Martion Spott, and he at least confirmed the problem with the Cessna in LOWI. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
> So, something seems to go wrong here. I recall a discussion on crash issues > on airports other than KSFO on the list, but thought that would have been > solved. I talked to Martion Spott, and he at least confirmed the problem > with the Cessna in LOWI. With c172 to be precise. c310 doesn'n crash, a4-yasim doesn't crash either. The other airports I prefer to use don't show this phenomenon but there still may be some Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem report on release 0.7.9
Hi, I just received a problem report from a German user on the released version 0.7.9 which I - unfortunately - was able to confirm in part. 1. Start at CL77 Santa Cruz leads to an immediate crash. 2. He reported a crash at Munich EDDM at start (e010n40 installed) which I could not confirm. 3. However, Start at Innsbruck LOWI gave me an immediate crash, too. BTW, starting from Munich I was not unable to see the alps. I did not fly for long, but I know they can be seen in MSFS shortly after the start (given proper visibility settings). This is the released Windows binary 0.7.9 (which shouldn't matter, though) and the default Cessna 172. So, something seems to go wrong here. I recall a discussion on crash issues on airports other than KSFO on the list, but thought that would have been solved. I talked to Martion Spott, and he at least confirmed the problem with the Cessna in LOWI. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
