Re: [Flightgear-devel] Startup position offsets (fg_init)
On 25 Aug 2008, at 03:25, Curtis Olson wrote: Hi James, I think this was all done intentionally because it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. The start-offset-m value I believe was added later to account for the difference in aircraft size. A starting position that works well to place the C172 at the end of the runway, might put the back half of the 747 off the end of the runway. Understood on both counts, but that means I think there is a bug in the glideslope code: On Sun, Aug 24, 2008 at 3:53 PM, James Turner wrote: Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. Hence my feeling that something isn't quite right - I understand why the 'polarity' of start-offset-m and offset-distance-nm are they way there are, but then it does seem as if the glideslope calculation will place the point in a silly place. From testing with the code, that does indeed seem to be the case. The fix would be as trivial as removing the '-1' term from that line, of course. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On 08/24/2008 01:53 PM, James Turner wrote: Doing this, I came across something which seems counter-intuitive to me: I agree, it's counterintuitive, to say the least. default azimuth to offset by is the *reciprocal* runway heading. This means to start 10nm 'out' from the threshold, one can use a positive value of 10 - I expected this to require a negative value. Good catch. I agree, there are many good reasons why a negative value would be appropriate here. I wonder if this is intentional, since it's the more common case that starting 'ahead' of the threshold, but equally it might be a bug - the azimuth is inverted to move from the runway centre 'back' to the threshold. Long-ago discussions indicate that it is intentional. But it is still a Bad Idea. The problem is, starting ahead of the threshold is only one use-case among many. It is not even remotely the most common case chez moi. It is a Bad Idea to simplify this one case at the cost of logic and consistency among the many other cases, such as positioning relative to enroute waypoints. On a tangentially related note, it appears that James Turner is wise enough to live by the dictum, principles and concepts first; terminology second. I mention this because previous discussions of this topic quickly degenerated into pedantic emphasis on the definition of distance (which is necessarily positive) to the exclusion of more usable concepts such as location-vectors and position-vectors along the number line. For years, the _Sport Model_ has represented offsets in the logical way, such that negative offsets are on the upstream side of the reference point, while positive offsets are on the downstream. side. Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On Mon, Aug 25, 2008 at 3:12 AM, James Turner wrote: On 25 Aug 2008, at 03:25, Curtis Olson wrote: Hi James, I think this was all done intentionally because it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. The start-offset-m value I believe was added later to account for the difference in aircraft size. A starting position that works well to place the C172 at the end of the runway, might put the back half of the 747 off the end of the runway. Understood on both counts, but that means I think there is a bug in the glideslope code: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On 08/25/2008 02:45 PM, Curtis Olson wrote: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? In my experience, the glideslope initialization feature has never worked. Not even once. I've tried it maybe 50 times on 10 occasions over the past two years. I tried it again just now. Details vary: *) If I specify distance and slope, a negative absolute altitude is one of the common results, *) If I specify altitude and slope, a wildly incorrect position is one of the common results. *) If I try it more than once, without exiting and restarting fgfs, NaN position with NaN altitude is one of the common results. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
Hmmm, ok I suppose that is possible. I have done this with an external FAA certified flight dynamics model, but I am letting the flightgear code compute the final longitude and latitude and altitude and just passing that over. This has worked as recently as 2 weeks ago. I don't know that I've tried this with any internal FDM's recently though. Can you give me an example that fails? This initial position code is a bit complicated since it perhaps tries too hard to decide what you *want* based on limited or missing inputs, but as far as I know it does work correctly. Regards, Curt. On Mon, Aug 25, 2008 at 5:33 PM, John Denker [EMAIL PROTECTED] wrote: On 08/25/2008 02:45 PM, Curtis Olson wrote: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? In my experience, the glideslope initialization feature has never worked. Not even once. I've tried it maybe 50 times on 10 occasions over the past two years. I tried it again just now. Details vary: *) If I specify distance and slope, a negative absolute altitude is one of the common results, *) If I specify altitude and slope, a wildly incorrect position is one of the common results. *) If I try it more than once, without exiting and restarting fgfs, NaN position with NaN altitude is one of the common results. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Startup position offsets (fg_init)
I'm writing some automated testing code for pieces of FG, so that I can experiment with changes to various internal bits of code with more confidence that I haven't broken anything. These aren't quite unit- tests (they test multiple areas of the code at once) and they're pretty crude, but any testing is better than none (and quicker than manual testing). Initially I've focused on the various things done by fgInitPosition, since this indirectly uses the Navaids and airports data, and potentially the environment code. Doing this, I came across something which seems counter-intuitive to me: There's a /sim/presets/offset-distance-nm property, which allows (logically enough) to offset the start position relative to, for example, a runway. What I've found is that for a runway, where the / sim/presets/heading-deg is initialised from the runway heading, the default azimuth to offset by is the *reciprocal* runway heading. This means to start 10nm 'out' from the threshold, one can use a positive value of 10 - I expected this to require a negative value. Line 771 of fg_init.cxx (double azimuth = heading + 180.0;) is the relevant piece of logic. I wonder if this is intentional, since it's the more common case that starting 'ahead' of the threshold, but equally it might be a bug - the azimuth is inverted to move from the runway centre 'back' to the threshold. Note there's also /sim/airport/runways/start-offset-m, which *is* 'forwards' from the threshold. Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. Anyway, that's my analysis, I'd love someone to check my logic and see if they concur or disagree. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
Hi James, I think this was all done intentionally because it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. The start-offset-m value I believe was added later to account for the difference in aircraft size. A starting position that works well to place the C172 at the end of the runway, might put the back half of the 747 off the end of the runway. Regards, Curt. On Sun, Aug 24, 2008 at 3:53 PM, James Turner wrote: I'm writing some automated testing code for pieces of FG, so that I can experiment with changes to various internal bits of code with more confidence that I haven't broken anything. These aren't quite unit- tests (they test multiple areas of the code at once) and they're pretty crude, but any testing is better than none (and quicker than manual testing). Initially I've focused on the various things done by fgInitPosition, since this indirectly uses the Navaids and airports data, and potentially the environment code. Doing this, I came across something which seems counter-intuitive to me: There's a /sim/presets/offset-distance-nm property, which allows (logically enough) to offset the start position relative to, for example, a runway. What I've found is that for a runway, where the / sim/presets/heading-deg is initialised from the runway heading, the default azimuth to offset by is the *reciprocal* runway heading. This means to start 10nm 'out' from the threshold, one can use a positive value of 10 - I expected this to require a negative value. Line 771 of fg_init.cxx (double azimuth = heading + 180.0;) is the relevant piece of logic. I wonder if this is intentional, since it's the more common case that starting 'ahead' of the threshold, but equally it might be a bug - the azimuth is inverted to move from the runway centre 'back' to the threshold. Note there's also /sim/airport/runways/start-offset-m, which *is* 'forwards' from the threshold. Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. Anyway, that's my analysis, I'd love someone to check my logic and see if they concur or disagree. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
