[Flightgear-devel] F-16 upgraded to 'production' status
Hi, I have been busy updating the F-16 flight computer lately which turned out the have quite some problems. After extensive (and many, many hours of) work I'm pleased to announce it is finished now. I know others have been using this FDM to model other aircraft, so I've added a bit of documentation in the file itself to explain what everything does. This might be a good time to upgrade the old F-16 based FDMs. The changes are mainly in the flight_control section, except for the addition of the CmDh table to the Pitch axis. Erik - 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] F-16 upgraded to 'production' status
On Fri, 15 Aug 2008 10:52:38 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Hi, I have been busy updating the F-16 flight computer lately which turned out the have quite some problems. After extensive (and many, many hours of) work I'm pleased to announce it is finished now. I know others have been using this FDM to model other aircraft, so I've added a bit of documentation in the file itself to explain what everything does. This might be a good time to upgrade the old F-16 based FDMs. The changes are mainly in the flight_control section, except for the addition of the CmDh table to the Pitch axis. Erik Great work. PRODUCTION release sounds good to me. Jon - 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] Nord 2501; Was: Particle Submodel OSG format
On jeu 14 août 2008, gerard robin wrote: SNIP With Noratlas, the last piston update, has made some change, now i get less power, i must update the Engine spec However i can take off with it (slowly, and carefully) Cheers No i was wrong, N2501 is right with the most recent JSBSim update , rather over powered than less. The real was said to have a Take-off field 810 m, which is OK. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] F-16 upgraded to 'production' status
On Friday 15 August 2008 09:52:38 Erik Hofman wrote: I have been busy updating the F-16 flight computer lately which turned out the have quite some problems. After extensive (and many, many hours of) work I'm pleased to announce it is finished now. I know others have been using this FDM to model other aircraft, so I've added a bit of documentation in the file itself to explain what everything does. Hi Erik, Nice to see you getting time to work on FG again! The F-16 does seem to fly very nicely now. The only request I have is for the Aircraft Help box - it would be great to have a few vital numbers there; rotation, stall, approach, touchdown speeds for example. I dare say a bit of googling (or reading the FDM config!) would reveal most of those but still it would be nice to have them available in-sim for quick reference. Cheers, AJ - 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] black out behavior
On jeu 14 août 2008, Erik Hofman wrote: Hi, Ever since I switched to the CVS version of FlightGear I wondered whether the black-out behavior really is that realistic . Although I never experienced it I couldn't imagine this would happen in real life, at least not with an anti-g suit. In an excerpt from a nasa document describing a simulation involving black-outs I got the following piece of text: blackout simulation: The algorithm used a direct relationship between the algorithm of the load factor a(n) and the algorithm of the time to blackout; the simulation used 300 sec to blackout at 5g and 10 sec to blackout at 9g, with simulatoed tunel vision during the interim period. Maybe this will help to make it more realistic. Erik I have not the answer :( , so, having access to an external parameter/property ( evaluated and given by the Model Aircraft developer) which modify the conditions/values of black-out would be the best. Now when using any modern fighter with G-Suit , we get the same black-out than we have with aerobatic Aircraft. Which is wrong. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] black out behavior
On ven 15 août 2008, gerard robin wrote: I have not the answer :( , so, having access to an external parameter/property ( evaluated and given by the Model Aircraft developer) which modify the conditions/values of black-out would be the best. Now when using any modern fighter with G-Suit , we get the same black-out than we have with aerobatic Aircraft. Which is wrong. Cheers Oups, Oups, Oups, I did not take care of the Cockpit View parameters, which are new to me when we are not there a long time we are faulty ( so i am ). Well, these parameters, can be customized. My apologize and many thanks to the developer Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] black out behavior
Erik Hofman wrote: Hi, Ever since I switched to the CVS version of FlightGear I wondered whether the black-out behavior really is that realistic . Although I never experienced it I couldn't imagine this would happen in real life, at least not with an anti-g suit. In an excerpt from a nasa document describing a simulation involving black-outs I got the following piece of text: blackout simulation: The algorithm used a direct relationship between the algorithm of the load factor a(n) and the algorithm of the time to blackout; the simulation used 300 sec to blackout at 5g and 10 sec to blackout at 9g, with simulatoed tunel vision during the interim period. Maybe this will help to make it more realistic. Agreed, and there is something annoying about blackout and HUD, when you can't see anything due to blackout effect, the HUD remains visible as nothing were happening... For sure that's not realistic at all :-) Alexis - 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] FGNavList oddity
I encountered the following code, in the middle of
FGNavList::findNavFromList:
==
// LOC, ILS, GS, and DME antenna's could potentially be
// installed at the opposite end of the runway. So it's not
// enough to simply find the closest antenna with the right
// frequency. We need the closest antenna with the right
// frequency that is most oriented towards us. (We penalize
// stations that are facing away from us by adding 5000 meters
// which is further than matching stations would ever be
// placed from each other. (Do the expensive check only for
// directional atennas and only when there is a chance it is
// the closest station.)
int type = station-get_type();
if ( d2 min_dist
(type == 4 || type == 5 || type == 6 || type == 12 ||
type == 13) )
{
double hdg_deg = 0.0;
if ( type == 4 || type == 5 ){
hdg_deg = station-get_multiuse();
} else if ( type == 6 ) {
int tmp = (int)(station-get_multiuse() / 1000.0);
hdg_deg = station-get_multiuse() - (tmp * 1000);
} else if ( type == 12 || type == 13 ) {
// oops, Robin's data format doesn't give us the
// needed information to compute a heading for a DME
// transmitter. FIXME Robin!
}
double az1 = 0.0, az2 = 0.0, s = 0.0;
SGGeod geod = SGGeod::fromCart(aircraft);
geo_inverse_wgs_84( geod, station-get_pos(), az1, az2,
s);
az1 = az1 - station-get_multiuse();
if ( az1 180.0) az1 -= 360.0;
if ( az1 -180.0) az1 += 360.0;
// penalize opposite facing stations by adding 5000 meters
// (squared) which is further than matching stations would
// ever be placed from each other.
if ( fabs(az1) 90.0 ) {
double dist = sqrt(d2);
d2 = (dist + 5000) * (dist + 5000);
}
}
=
Now, there's two bad things here: (I think)
- in the DME case (type == 12 or 13), hdg is left 0.0
- hdg, having been computed, isn't then used: I assume it should
replace the 'station-get_multiuse' on this line:
az1 = az1 - station-get_multiuse();
It'd be great if someone who knows more about this code could comment
on how 'important' it is, since it's only doing the right thing in the
ILS/LOC case (the GS will be wrong because 'multiuse' contains other
data, and DME because multiuse is empty)
It feels like this ought to cause visible weirdness with nav-radios,
but I don't have a strong understanding for how 'bad' this might be.
Maybe we only actually encounter this code for ILS transmitters, so
the bug is masked?
Any light that can be shed, would be appreciated.
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] FGNavList oddity
James,
I was perusing the cvs logs online for this source file and this code goes
back quite a ways ...
http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?view=log
Revision *1.7* -
(viewhttp://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?revision=1.7view=markup)
(downloadhttp://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?revision=1.7)
(annotatehttp://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?annotate=1.7)
- [select for
diffs]http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?r1=1.7view=log
*Mon Jul 19 18:02:00 2004 UTC* (4 years ago) by *curt*
Branch:
*MAIN*http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?view=logpathrev=MAIN
Changes since *1.6: +53 -6 lines*
Diff to previous
1.6http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?r1=1.6r2=1.7
Ed Sirett submitted a patch to consider antenna orientation when searching
for localizers. I further hacked this to support GS and DME transmitters
(although Robin's DME transmitter data doesn't convey orientation
unfortunately.)
So it looks like you've stumbled on a chunk of code that could use some
tidying up. It's strange, hdg_deg seems totally unused. Clearly something
weird there crept in. It does seem to make sense to use it below as you
suggest. For DME's maybe we always want the closest one anyway, but the
code as it stands could arbitrarily penalize one over the other if there are
two dme's on the same frequence for a single runway.
Since this code came from a user patch originally, I'd be happy to give you
the green light to improve it.
Regards,
Curt.
On Fri, Aug 15, 2008 at 3:30 PM, James Turner wrote:
I encountered the following code, in the middle of
FGNavList::findNavFromList:
==
// LOC, ILS, GS, and DME antenna's could potentially be
// installed at the opposite end of the runway. So it's not
// enough to simply find the closest antenna with the right
// frequency. We need the closest antenna with the right
// frequency that is most oriented towards us. (We penalize
// stations that are facing away from us by adding 5000 meters
// which is further than matching stations would ever be
// placed from each other. (Do the expensive check only for
// directional atennas and only when there is a chance it is
// the closest station.)
int type = station-get_type();
if ( d2 min_dist
(type == 4 || type == 5 || type == 6 || type == 12 ||
type == 13) )
{
double hdg_deg = 0.0;
if ( type == 4 || type == 5 ){
hdg_deg = station-get_multiuse();
} else if ( type == 6 ) {
int tmp = (int)(station-get_multiuse() / 1000.0);
hdg_deg = station-get_multiuse() - (tmp * 1000);
} else if ( type == 12 || type == 13 ) {
// oops, Robin's data format doesn't give us the
// needed information to compute a heading for a DME
// transmitter. FIXME Robin!
}
double az1 = 0.0, az2 = 0.0, s = 0.0;
SGGeod geod = SGGeod::fromCart(aircraft);
geo_inverse_wgs_84( geod, station-get_pos(), az1, az2,
s);
az1 = az1 - station-get_multiuse();
if ( az1 180.0) az1 -= 360.0;
if ( az1 -180.0) az1 += 360.0;
// penalize opposite facing stations by adding 5000 meters
// (squared) which is further than matching stations would
// ever be placed from each other.
if ( fabs(az1) 90.0 ) {
double dist = sqrt(d2);
d2 = (dist + 5000) * (dist + 5000);
}
}
=
Now, there's two bad things here: (I think)
- in the DME case (type == 12 or 13), hdg is left 0.0
- hdg, having been computed, isn't then used: I assume it should
replace the 'station-get_multiuse' on this line:
az1 = az1 - station-get_multiuse();
It'd be great if someone who knows more about this code could comment
on how 'important' it is, since it's only doing the right thing in the
ILS/LOC case (the GS will be wrong because 'multiuse' contains other
data, and DME because multiuse is empty)
It feels like this ought to cause visible weirdness with nav-radios,
but I don't have a strong understanding for how 'bad' this might be.
Maybe we only actually encounter this code for ILS transmitters, so
the bug is masked?
Any light that can be shed, would be appreciated.
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
Re: [Flightgear-devel] FGNavList oddity
On 08/15/2008 01:30 PM, James Turner wrote: I encountered the following code, in the middle of FGNavList::findNavFromList: [snip] Now, there's two bad things here: (I think) - in the DME case (type == 12 or 13), hdg is left 0.0 - hdg, having been computed, isn't then used: I assume it should replace the 'station-get_multiuse' on this line: az1 = az1 - station-get_multiuse(); Good catch. Actually, there's more than two bad things here. It'd be great if someone who knows more about this code could comment on how 'important' it is, since it's only doing the right thing in the ILS/LOC case (the GS will be wrong because 'multiuse' contains other data, and DME because multiuse is empty) Before we discuss the code in detail, we should try to figure out what is the goal or purpose of this code. If the goal is realism, it will be a very short discussion, because the concepts on which this code is based are seriously unrealistic, even in the LOC case. *) The aiming of localizer antennas does not work the way this code assumes. Not even close. *) This is well known and officially documented in e.g. the Aeronautical Information Manual. Look under Service Volume. *) Pilots depend on the service volume behaving as documented. -- This is particularly obvious in the case of Back Course approaches. -- This is particularly obvious in the case of a Missed Approach where the pilot follows the localizer course well past the antenna. One of my maxims is If you're not prepared for the miss, you're not prepared for the approach -- Et cetera. You get the idea. It feels like this ought to cause visible weirdness with nav-radios, but I don't have a strong understanding for how 'bad' this might be. It's bad. Maybe we only actually encounter this code for ILS transmitters, so the bug is masked? Even the ILS/LOC behavior is seriously unrealistic. = If you want to know how it works in the real world, consider e.g. the paired transmitters for KJFK RWY 4L/22R. -- ILS RWY 4L uses frequency 110.9, callsign I-HIQ -- ILS RWY 22R uses frequency 110.9, callsign I-IWY Now the trick is that in the real world, you never have both transmitters active at the same time. There's a switch in the tower. It's just that simple. Funny story: This is one of the many reasons why pilots are trained to always identify the navaid callsign. I once had a student pull out the ILS RWY 4L approach plate and try to follow it while the I-HWY transmitter was active. He got rather spectacularly confused. (Ever since then, he has been fastidious about IDENTing navaids.) === Possibly constructive suggestions: 1) In the case of paired transmitters, turn on the one that serves the runway _favored by the wind_. Do this regardless of the location of the aircraft. Remark: This works even in multiplayer situations. Remark: Put a heavy low-pass filter on the choice of runway, so it doesn't go nuts if the wind is variable. Maybe cooperate with the ATIS code so that the active runway reported by ATIS is the runway with the active transmitter. 2) Fix the many other bugs in the service-volume code. Note that there is code in the Sport Model to handle false LOC courses, false GS paths, extended LOC volumes, and other stuff you encounter in the real world. - 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] FGNavList oddity
On 15 Aug 2008, at 23:07, John Denker wrote: Possibly constructive suggestions: 1) In the case of paired transmitters, turn on the one that serves the runway _favored by the wind_. Do this regardless of the location of the aircraft. Remark: This works even in multiplayer situations. Remark: Put a heavy low-pass filter on the choice of runway, so it doesn't go nuts if the wind is variable. Maybe cooperate with the ATIS code so that the active runway reported by ATIS is the runway with the active transmitter. Funnily enough, that's the next step in my runways code. However, selectively enabling and disabling ILS/LOC/GS navaids will take a bit more engineering. I think it's possible, since Durk's runway prefs logic knows which runway(s) are active for landings. And that code already has the low-pass filter, AND soon will be hooked up to the ATIS code. 2) Fix the many other bugs in the service-volume code. Note that there is code in the Sport Model to handle false LOC courses, false GS paths, extended LOC volumes, and other stuff you encounter in the real world. I don't know what the 'Sport Model' is, can you elaborate? If you could enumerate the issues here, in a new thread, that'd be interesting. I'm not promising to work on any issues besides this one, but at least we'd have the problems tracked in a searchable, archived place. Cheers, 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
[Flightgear-devel] FGPositioned refactoring
I'm planning to do a slightly intensive re-factoring - creating a base class where one didn't exist before. The (draft) base class is attached - it will become a base for the following: FGAirport FGRunway FGFix FGNavRecord ATCData The members are pretty uncontroversial, I think. What I'll do is keep the 'old' accessors / members on each derived class, to avoid a massive diff, and clean them up in separate, boring patches. Once the base class is in, and nothing is broken, I'll proceed as follows: - make FGFix, FGRunway and ATCdata be 'pointery', so all these things are living on the heap and do proper virtual calls. I'll actually make them SGReferenced I hope, but I need to see how much more work that will be. (FGNavRecord is already an SGReferenced, for example) - create a centralised, SGBucket-based spatial index of the whole lot, with some query methods: static FGPositionedList FGPositioned::findWithinRangeOfLocation(double lat, double lon, double rangeNm); static FGPositionedList FGPositioned::findWithIdent() static FGPositionedList FGPositioned::findClosestWithIdent() (and of course some variants / overloads to filter by type. I need to check about overloading statics, but ideally FGNavRecord::findWithinRangeOfLocation would be overloaded to only return navaids, etc, etc). - gradually simplify or kill off the various FGblahList classes in favour of unified queries on this (i.e clean up the call sites). This includes removing the 'poor mans' spatial index in navlist, the total *absence* of a spatial DB in airports, the SGBucket-based one in commlist.cxx. At the same time I'd let the derived classes keep their specialised indices and query methods - eg airport idents are unique, navaids and ATCDatas can be indexed by frequency, and so on. (this last step will take some time :) The motivation for this is of course being able to build my NAV display, but it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data. And indeed that's what Dave Luff's GPS code looks like - just using its own internal waypoint and flightplan classes for these jobs, which is one of the many things I hope to improve. Incidentally, the unified 'type' enum will replace several existing type fields - the FGAirport type member, the FGRunway taxiway flag, the FGNavRecord type, and the ATCData type. There's also scope to add more - I've optimistically included an 'OBSTACLE' type, for example, on the hope that I can add find an existing obstacle DB to import. In any case, adding types is cheap. Comments on, or objections to, this plan, would be greatly appreciated. Note I hate the name 'FGPositioned' but can't think of a better name that accurately reflects what the class does. I'll buy a beer/beer-substitute for anyone who comes up with a shorter, more meaningful class name. Cheers, James positioned.hxx Description: Binary data - 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
