[Flightgear-devel] runway lights
Hi guys! Still try to implement runway lights find some section in tileentry.cxx RWY_LIGHTS but i think it's unfinished also when i looked in tile_entry.cxx i found various runway lights initialsations but i don't understand angular_size in setcolor() function and elev_size and azimut_size in setcolor2 function could you please explain it? also i find section in main.cxx that read lights from object.txt does someone use it? Thanx in advance bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
Jon S. Berndt wrote: Alex wrote: For starters, can the JSB filters (etc) stuff be used without JSBSim? The base class of all JSBSim classes - including the FCS classes - is FGJSBBase. So, technically, no. This would be a good feature to look at breaking out of the FDM. At its most reductionist, a FCS system compares (1) pilot control inputs and (2) FDM output to produce control surface positions. None of that requires access to the internals of the FDM. A well-designed FCS would work with any conceivable FDM. Here's a plausible black-box model: the FCS subsystem takes its control inputs from the /controls/ property tree, and places its output into the /fcs/ tree. So, we'd modify the FDM configurations to look there instead, and no code change would be necessary. We could (unsuccessfully) fly a C172 with a F-16 fly-by-wire system without change. The way I see it now (and it's just off the top of my head) is that *IF* the JSBSim config file specifies an autopilot for an aircraft, then that autopilot would be used instead of the one from the FlightGear side. This is because I'd also like the ability to run it with JSBSim standalone. I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. 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] altitude hold problem
I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. There certainly are a lot of options, including the ones you specify above. My plan is to keep the proposed autopilot classes under the JSBSim base class structure and use already available JSBSim classes as building blocks. Certainly another option is for a separate autopilot code to be built completely apart from JSBSim (indeed this already exists), but I'd still want to build an autopilot for JSBSim - whether or not it even got used. The class structure, config file arrangement, etc. are all already there. The extra code an autopilot would use would be minimal. Also, FlightGear is not the only user of JSBSim, and I suspect an autopilot feature would be useful for them. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine wrote:
Geoff McLane writes:
When running your fgfs.exe the log ends abruptly with
...
/autopilot
/PropertyList
* After fgSaveFlight()
* Before globals-saveInitialState()
Aha this is my xtra instrumentation in fg_init()
bool fgInitSubsystems( void ) {
...
#define TEST_SAVE_INITIAL_STATE 1
#ifdef TEST_SAVE_INITIAL_STATE
// ADDED NHV
SG_LOG( SG_GENERAL, SG_INFO, * Before fgSaveFlight() );
fgSaveFlight(cout);
SG_LOG( SG_GENERAL, SG_INFO, * After fgSaveFlight() );
#endif
SG_LOG( SG_GENERAL, SG_INFO, * Before
globals-saveInitialState() );
globals-saveInitialState();
SG_LOG( SG_GENERAL, SG_INFO, * After
globals-saveInitialState() );
return true;
}
DaveM
Have you any idea why whe fgSaveFlight() succeeds saveInitialState() won't
or perhaps some insight as to how Goeff can best debug this as to what is
bogus
in the properties
Goeff
Can you put a breakpoint at the globals-saveInitialState(); call
and then inspect the properties tree for a BOUGUS value ??
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb CVS question
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.01.16 15:37]: I'm still trying to come up to speed and if I am going to do any serious work I need to be able to do CVS checkouts. I downloaded wincvs and am following instructions (I think) on the flightgear website. Here's what I get: $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7.8 login This is incorrect. The directory ends with -0.7 not -0.7.8. See http://www.flightgear.org/cvsResources/anoncvs.html. -- Cameron Moore [ Plan to be spontaneous tomorrow. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] embedded screenshot httpd server
On Thu, 17 Jan 2002 07:09, you wrote: Thanks to Norman Vine's unique combination of genius hackery we now support this as an option: http://128.101.142.57:5501/ Server up and running for a short time so check it out now before I take it down. Um. All I see is gibberish characters. David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] embedded screenshot httpd server
On Thu, 17 Jan 2002 08:09, you wrote: On Thu, 17 Jan 2002 07:09, you wrote: Thanks to Norman Vine's unique combination of genius hackery we now support this as an option: http://128.101.142.57:5501/ Server up and running for a short time so check it out now before I take it down. Um. All I see is gibberish characters. Hmm, It's right now. Where is that flying? David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb CVS question
Thanks for catching my error. Unfortunately, I am getting the same result when I type it correctly. So in addition to me being dumb, there is still something else wrong. Mark -Original Message- From: Cameron Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 2:41 PM To: '[EMAIL PROTECTED]' Subject: Re: [Flightgear-devel] dumb CVS question * [EMAIL PROTECTED] (Boslough, Mark B) [2002.01.16 15:37]: I'm still trying to come up to speed and if I am going to do any serious work I need to be able to do CVS checkouts. I downloaded wincvs and am following instructions (I think) on the flightgear website. Here's what I get: $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7.8 login This is incorrect. The directory ends with -0.7 not -0.7.8. See http://www.flightgear.org/cvsResources/anoncvs.html. -- Cameron Moore [ Plan to be spontaneous tomorrow. ] ___ 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] embedded screenshot httpd server
Curtis L. Olson writes: Thanks to Norman Vine's unique combination of genius hackery we now support this as an option: http://128.101.142.57:5501/ Server up and running for a short time so check it out now before I take it down. Approaching KLAX @ 14,500', then on to KSAN, KPHX, KTUS, KDFW, KMSY, KJAX, KMIA, KORF, KJFK, KBOS, KORD, KMSP, and finally KANE. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] altitude hold problem
On Wed, 2002-01-16 at 10:13, Andy Ross wrote: Jon S. Berndt wrote: Alex wrote: For starters, can the JSB filters (etc) stuff be used without JSBSim? The base class of all JSBSim classes - including the FCS classes - is FGJSBBase. So, technically, no. This would be a good feature to look at breaking out of the FDM. At its most reductionist, a FCS system compares (1) pilot control inputs and (2) FDM output to produce control surface positions. None of that requires access to the internals of the FDM. A well-designed FCS would work with any conceivable FDM. For 90% of what FG is used for this is probably true. For the general case, however, it depends on how much data you want to put into the property tree and/or on the bus. Even moderately sophisticated flight control systems can be dependent on quite a number of parameters. Here's a plausible black-box model: the FCS subsystem takes its control inputs from the /controls/ property tree, and places its output into the /fcs/ tree. So, we'd modify the FDM configurations to look there instead, and no code change would be necessary. We could (unsuccessfully) fly a C172 with a F-16 fly-by-wire system without change. The way I see it now (and it's just off the top of my head) is that *IF* the JSBSim config file specifies an autopilot for an aircraft, then that autopilot would be used instead of the one from the FlightGear side. This is because I'd also like the ability to run it with JSBSim standalone. I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. Again, viable for 90% of what FG does, but not for the general case. Any FCS that incorporates stability augmentation, for example, will be very specific to that aircraft (and sometimes even sub-models). 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] altitude hold problem
On Tue, 2002-01-15 at 18:52, Alex Perry wrote: On Tue, 2002-01-15 at 07:19, Christian Mayer wrote: What we really need here is for our resident flight control systems expert to whip us up a program for generating the control law gains based on the config file ... It's probably easier to adapt the autoconfiguration algorithms for PID controllers so that the autopilot derives the parameters automatically. It typically only needs to be done once. ___ 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] Altitude Calculation
John Wojnaroski wrote:
In steam.cxx the pressure datum is set to some setting that represents
atmospheric pressure. Okay, so far
But can't find any connection between the two.
...
In the present FlightGear code, the atmospheric pressure (the_STATIC_inhg) used to
calculate the altimeter reading is itself calculated from the altitude by a simple
formula. This may seem pointless or confusing. The only reason it converts altitude
to pressure and then back to altitude (and does not just display the known altitude
directly) is to prepare for when we will replace the first part of this calculation.
In FGSteam::_CatchUp() we need to replace the pressure calculation with something like:
sgVec3 plane_pos = { cur_fdm_state-get_Latitude(),
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Altitude() * SG_FEET_TO_METER };
double static_inhg = WeatherDatabase-get(plane_pos).AirPressure * (0.01 /
INHG_TO_MB);
set_lowpass ( the_STATIC_inhg, static_inhg, dt );
This will drive the altimeter directly from the pressure given by Christian Meyer's
weather model. I have tried this and it gives good results.
My guess is that the actual variations in pressure gradients (Highs and
Lows) is not modeled and we fly in a
uniform atmosphere so that runway elevation at KLAX and KJFK have the same
baro setting. Which says I can
use the altimeter value set at takeoff to runway elevation as the *elev*
value to calculate navigational positions, ranges, and
things like glideslope positions. And this is also the *h* value used in the
EOMs.
Is this correct? Or is there a non-uniform atmospheric model corrected for
local temperature and pressure?
I don't know what *h* or *elev* or EOM are, or what kind of atmosphere variations are
modelled.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
From: Andy Ross In fact, this is a good example: a real F-16A (Dunno about the C) flight control computer takes its input from a set of gyros and from the position of the stick, and that's it The F-16 DFCS (beginning with Block 40) - and I suspect to some degree also the F-16A model - also requires the inputs of a rather lot of switch positions (commonly referred to as notes), e.g. pitch switch position, absolute value of phi greater than some value, WOW, roll switch position, standby gains enabled, control stick steering force greater than some value, other notes, etc. These are very aircraft specific. So, as you state below, yes the FCS needs to know some very specific aircraft information. The issue isn't whether the FCS needs to know specific per-aircraft information. Of course it does. The issue is whether the FCS *code* requires access to the internals of the FDM. I argue that it does not. I'd tend to agree with you, there. The only thing I am really arguing is that for JSBSim: 1) The FCS is already being modeled. We want to do it. We like doing it. 2) We *needed* to do it. There simply wasn't anything like it prior to JSBSim, and still isn't AFAIK. 3) Is there anyone else out there who can model a generic FCS and/or wants to? 4) The class hierarchy we have produced already includes the FCS building blocks and the class hierarchy will be kept intact. 5) An autopilot would be a natural outgrowth of the FCS code we currently have. 6) The FCS theoretically doesn't need to know the innards of the FDM, but it sure makes it easier - perhaps even removing a level of extraneous abstraction. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] altitude hold fix
I've got some values that seem to work in the current autopilot code with the c310. They are: min_climb = 85.0 kts best_climb = 107.0 kts TargetClimbRate = 1500 fpm Also there is this adjustment factor (code snippet from newauto.cxx aprox line 697): // calculate proportional error prop_error = error; prop_adj = prop_error / 4000.0; The numbers for the c172 are 70, 75, 500, 2000.0 (in the same order as those listed above). If someone could spec the XML (which file and keywords) I'd be glad to modify the autopilot code to use them. What should this adjustment factor be called? It basically strikes a balance in a simplistic way between over and under adjusting elevator trim. It's not as good as it could be, but it'll provide a basic altitude hold function for now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
Martin. P.S.: I _really_ believe it would be wise to separate FDM and FCS using a clean interface - but this is different from the above ;-) In JSBSim it already is. There appears to be a misconception that the FDM and FCS are inappropriately linked together. In JSBSim the atmosphere, rotational and translational dynamics, ground reactions, aerodynamic forces, mass properties, flight control system, propulsion, trimming, initialization, etc. are all separate models/entities. Together they comprise everything one needs to simulate an aircraft non-visually. This is one thing JSBSim is designed to do - to simulate aircraft in batch mode or to be the flight model guts for a visual simulator. We keep the FCS code pieces in a separate directory from the rest of the JSBSim FDM code. The FCS class manages a set of FCS building blocks. These building blocks can get the values of parameters they need from a single call to a retrieval mechanism, GetParameter(). Given this mission goal for the JSBSim class hierarchy, we are doing exactly what we set out to do, and in a wise way, I submit. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] embedded screenshot httpd server
Curtis L. Olson writes: Cameron Moore writes: * [EMAIL PROTECTED] (Curtis L. Olson) [2002.01.16 15:11]: Thanks to Norman Vine's unique combination of genius hackery we now support this as an option: http://128.101.142.57:5501/ Server up and running for a short time so check it out now before I take it down. Weight On Wheels!! I mean...WOW!! Nice work, Norman. BTW, where's the panel/hud? Yes, send all complaints directly to Norman. :-) I do think that for this situation it would be nice to include panel/hud if they are activated. i.e. the screen shot server shows exactly what the application is showing. The panel and HUD really aren't that useful with the lower image resolution BUT. I think You could run a Properties server as well as an ImageServer and get the readouts that way :-)) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
