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
--- 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 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. HH James msg02961/pgp0.pgp Description: PGP signature
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 PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great
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
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
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
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
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
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
--- 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
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
* [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
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
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
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
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
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
