Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 6, 2005 10:28 pm, Lee Elliott wrote: I'll try modelling a few bits and bobs if that'll help. That will be great. Thank you. Texturing isn't really my forte and I've still got to do the MiG-15... I notice that in the CVS a few days ago. It was a decent surprise. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 7, 2005 08:28 am, Karsten Krispin wrote: Great work so far! :) Thank you. =) What exactly is beeing ment by scripting and sidestick? If you mean to programm a more or less functional Airbus-Cockpit with its Fly-By-Wire capabilities (Yes.. I also mean that typical stuff around FBW, flight envelope protection and so on..) and some basic FMC and FCU functions? - Luckily I also have had such an idea. Unfortunately I did not have the time to become familiar with this stuff. Yes, I meant the FBW system with all the flight envlope protection (the fun stuff). However, I also have quite a few things on my mind as well (the boring stuff). The first thing I have to deal with is the way, the XML-Instruments work. Is it possible to use the XML-Instruments in a 3d-Cockpit or do you have to rewrite the whole stuff to animations? As far as I know, the instruments that you see ARE the XML-Instruments that you referred to. Unfortunately, I have absolutely no experience in this area. Perhaps those who had experience with instruments can answer your question better. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
The version of FlightGear used for the MIADC show in May contains a fan/turbine model based on physics and thermo equations, a different approach to tank/engine selection to handle the 747 fuel system, changes in the control packet, and an update to the data packets. It might not be practical to try and incorporate these into the CVS baseline .I'm not sure and not all that conversant on how to create all the ifdefs and other compile/run time options or xml files to handle all the deltas. However, the source is there for anyone brave enough have a go at it or just to consider if it might be feasible. As I recall, Curt first created a diff file against the then current CVS baseline, next ran patch, and IIRCC the build was very clean. Go to http://www.lfstech.com and browse over to the download page. The file is miadc.tgz. John W. Hi, John: Very nice. I looked at FGTurbine.cpp. A couple of things: 1) Of course, it would be nice to incorporate the JSBSim changes into the current JSBSim CVS. However, as you may know, JSBSim has undergone major revisions compared to the version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving the new JSBSim code into FlightGear development CVS. So, to incorporate your changes, the Load() method will need to conform to the use of the new XML parsing method. 2) Question: Is your turbine model generic, or specific to the 747? 3) Did you make note (in code or whatever) of exactly which files you modified? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
Am Samstag, 8. Oktober 2005 06:44 schrieb Ampere K. Hardraade: Yes, I meant the FBW system with all the flight envlope protection (the fun stuff). However, I also have quite a few things on my mind as well (the boring stuff). Is it possible that you have a manual of the Airbus, or from where do you get your ideas? Because the Airbus-System are working intern more or less in the same way. Type-Rating issue on so on... So, I thought we first write a core. That one could be extended on one hand to an A32X/330/340- and on the other hand to an A380 cockpit. Here, a manual could be helpfull. As far as I know, the instruments that you see ARE the XML-Instruments that you referred to. Unfortunately, I have absolutely no experience in this area. Perhaps those who had experience with instruments can answer your question better. I also got an answer from Steve Knoblock. He said, as you assumed as well, that the XML-Instruments are the one displayed in an 3D-Cockpit. Now there is still one point: When programming an FMC and the to this according Navigation Display, we need a possibility to spawn objects on runtime to place Waypoints in it and connect them and so on. Is there a way like in HTML with JavaScripts DOM? Karsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Jon Berndt writes: 1) Of course, it would be nice to incorporate the JSBSim changes into the current JSBSim CVS. However, as you may know, JSBSim has undergone major revisions compared to the version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving the new JSBSim code into FlightGear development CVS. So, to incorporate your changes, the Load() method will need to conform to the use of the new XML parsing method. Out of interest, did Mathias ever manage to fix the gear jitter at stationary with his fancy integration scheme, and if so will it be going into FlightGear when you merge up next? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
Out of interest, did Mathias ever manage to fix the gear jitter at stationary with his fancy integration scheme, and if so will it be going into FlightGear when you merge up next? Cheers - Dave No. (I hope this doesn't open up a can of worms ...) Though it is acknowledged that Mathias' fix would have worked well, and is mathematically precise, the code overhead was sophisticated, large-ish, and somewhat complex - an evaluation that is, of course, open to interpretation and difference of opinion. The quandary I always face as development coordinator is in balancing design goals and actual capabilities. I had to consider the needs and perceived comfort level of the target audience[s], as well as myself. It led to a lot of really excruciatingly uncomfortable choices, some of which were so personally vexing that I continually put them off. At this point, yes, the gear still jitters, and it is still a high priority to be addressed. The route I prefer to take - at this time - is best described this way: The EOM and integration scheme now in use (which Mathias also adeptly refined) works quite well for almost anything that anyone wants to do with JSBSim. The single most important remaining problem that involves the dynamic math model is the same problem that the literature shows afflicts many other simulators: landing gear modeling at low and zero velocity. I do not feel it is the best solution at this time to consider a new and major change to the integration scheme in order to address this one problem. There are probably a few good approaches to fixing the gear problem - and it does need to be fixed. One good one is presented in an AIAA paper (AIAA-200?-4303). In that paper, the tricycle approximation is described. At some point, the integration scheme in JSBSim will probably be revisited, after some other approaches in JSBSim are modified. The gear jitter problem will be addressed. Right now there are other pressing needs. I don't know what else to say ... Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Hi Jon Jon Berndt wrote: The version of FlightGear used for the MIADC show in May contains a fan/turbine model based on physics and thermo equations, a different approach to tank/engine selection to handle the 747 fuel system, changes in the control packet, and an update to the data packets. It might not be practical to try and incorporate these into the CVS baseline .I'm not sure and not all that conversant on how to create all the ifdefs and other compile/run time options or xml files to handle all the deltas. However, the source is there for anyone brave enough have a go at it or just to consider if it might be feasible. As I recall, Curt first created a diff file against the then current CVS baseline, next ran patch, and IIRCC the build was very clean. Go to http://www.lfstech.com and browse over to the download page. The file is miadc.tgz. John W. Hi, John: Very nice. I looked at FGTurbine.cpp. A couple of things: 1) Of course, it would be nice to incorporate the JSBSim changes into the current JSBSim CVS. However, as you may know, JSBSim has undergone major revisions compared to the version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving the new JSBSim code into FlightGear development CVS. So, to incorporate your changes, the Load() method will need to conform to the use of the new XML parsing method. BTW your comment just pinged my memory. There are a few more changes to individualize engine performance like turbine/compressor efficiencies, hydraulics, etc. contained in the xml files for the 747. 2) Question: Is your turbine model generic, or specific to the 747? Its generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. 3) Did you make note (in code or whatever) of exactly which files you modified? The FGTurbine code is replaced en masse. No, sorry did not, but you should be able to run a diff. It's been a few months since I worked in that area, recall some changes in the FGEngine, and a few other areas to handle loading in the other engine parameters from the xml files. Probably makes more sense to wait for the next JSBSim release. I'll probably revisit that code in the next few months for another project and update it as needed. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
John Wojnaroski wrote: It's generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. Is this the paper: --- A Java simulator for teaching gas turbine operation John A. Reed and Abdollah A. Afjeh (Toledo, Univ., OH) AIAA-1997-850 Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9, 1997 --- I can't find it anywhere online. The FGTurbine code is replaced en masse. No, sorry did not, but you should be able to run a diff. It's been a few months since I worked in that area, recall some changes in the FGEngine, and a few other areas to handle loading in the other engine parameters from the xml files. Probably makes more sense to wait for the next JSBSim release. I'll probably revisit that code in the next few months for another project and update it as needed. Sounds good. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 19
I noticed recently that electrical outputs still show a voltage (frozen)
when a switch is shut off.Is there a reason for this ... or is it a work
in progress?
The reason I ask is that I want to animate lights by the voltage rather
than switch position ... (dimming lights as the battery voltage drops ,
etc...).I just want to know if this is the way it is going to operate ,
and I can change my animations (I'm currently working on the
overhead light switch panel in the B1900D).Thanks in advance, I know how
busy everyone is .Cheers
I am still learning the electrical system model. I like to see all the
electrical devices and switches work as in real life. If the master
avionics switch is off or the battery is dead, the autopilot should
not be displaying anything or operating.
For the autopilot, I set a power-good property (like mainboards have)
and use NASAL to check for sufficient output on the autopilot bus. For
example:
ap_pwr = getprop(/systems/electrical/outputs/autopilot[0]);
if( ap_pwr = 0.3) {
print(Digitrak: Power Good);
setprop(Internal, power-good, on);
} else {
print(Digitrak (Warning): Insufficient power.);
setprop(Internal, power-good, off);
}
This seems to work well. The Digitrak requires 0.3 amp.
On the other hand, I am still confused about some aspects of the
electrical system.
/systems/electrical/volts
/systems/electrical/amps
both seem to be read only properties. I suppose this makes sense, if
these are just monitoring the flow (but at what point?) and the system
is modeled as suppliers and outputs of electricity. Any adjustments
would be made at the supply side.
I can change
/systems/electrical/serviceable
but it appears to do nothing.
However,
/systems/electrical/suppliers/alternator
/systems/electrical/suppliers/battery
/systems/electrical/suppliers/external
are also read only. It appears all the outputs are ready only
/systems/electrical/outputs/*
I am left looking for where the actual source of electrical power is
specified. Looking at the electrical.xml the properties are defined
here.
I can change the initial value of the battery in amps from here (shows
up /systems/electrical/suppliers/battery), but lowering it to 5 amps
did not seem to affect the a/c.
Okay, if I set both battery and alternator to 0.1 amps in the config,
my autopilot fails power good. It appears the turn coordinator also
fails. Flaps still work (this is the Cessna). Radios work. ADF works.
Clock works. Fuel, Temp, Flow gauges all work, the AMPs show zero.
This suggests many instruments do not check the electrical properties.
The a/c engine turns over and works fine without a battery or
alternator (magneto?).
I am unsure how the output properties are affected by switches or if
they can be.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Jon Berndt wrote: John Wojnaroski wrote: It's generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. Is this the paper Might be or a derivative work, don't recognize the second author --- A Java simulator for teaching gas turbine operation John A. Reed and Abdollah A. Afjeh (Toledo, Univ., OH) AIAA-1997-850 Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9, 1997 --- I can't find it anywhere online. Hmm, neither can I and can't remember how -- it was a few years back. The link may be gone. At any rate, I uploaded a pdf file to the lfstech download page. You can find it there. Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 19
Syd and Steve,
Check out the newer nasal based electrical system for the C172. I just
had too much trouble getting the old xml based system to really work the
way I was hoping it might. The nasal based approach seemed to work out
so much better for me. The logic ends up being pretty much the same,
but I found it to be a lot easier to model some of the more subtle
electrical system behavior with nasal ... probably because it's easier
to cheat and fudge things when needed. :-)
But there's no reason you can't make every switch and circuit breaker
and light work just like the real aircraft ...
Curt.
Steve Knoblock wrote:
I noticed recently that electrical outputs still show a voltage (frozen)
when a switch is shut off.Is there a reason for this ... or is it a work
in progress?
The reason I ask is that I want to animate lights by the voltage rather
than switch position ... (dimming lights as the battery voltage drops ,
etc...).I just want to know if this is the way it is going to operate ,
and I can change my animations (I'm currently working on the
overhead light switch panel in the B1900D).Thanks in advance, I know how
busy everyone is .Cheers
I am still learning the electrical system model. I like to see all the
electrical devices and switches work as in real life. If the master
avionics switch is off or the battery is dead, the autopilot should
not be displaying anything or operating.
For the autopilot, I set a power-good property (like mainboards have)
and use NASAL to check for sufficient output on the autopilot bus. For
example:
ap_pwr = getprop(/systems/electrical/outputs/autopilot[0]);
if( ap_pwr = 0.3) {
print(Digitrak: Power Good);
setprop(Internal, power-good, on);
} else {
print(Digitrak (Warning): Insufficient power.);
setprop(Internal, power-good, off);
}
This seems to work well. The Digitrak requires 0.3 amp.
On the other hand, I am still confused about some aspects of the
electrical system.
/systems/electrical/volts
/systems/electrical/amps
both seem to be read only properties. I suppose this makes sense, if
these are just monitoring the flow (but at what point?) and the system
is modeled as suppliers and outputs of electricity. Any adjustments
would be made at the supply side.
I can change
/systems/electrical/serviceable
but it appears to do nothing.
However,
/systems/electrical/suppliers/alternator
/systems/electrical/suppliers/battery
/systems/electrical/suppliers/external
are also read only. It appears all the outputs are ready only
/systems/electrical/outputs/*
I am left looking for where the actual source of electrical power is
specified. Looking at the electrical.xml the properties are defined
here.
I can change the initial value of the battery in amps from here (shows
up /systems/electrical/suppliers/battery), but lowering it to 5 amps
did not seem to affect the a/c.
Okay, if I set both battery and alternator to 0.1 amps in the config,
my autopilot fails power good. It appears the turn coordinator also
fails. Flaps still work (this is the Cessna). Radios work. ADF works.
Clock works. Fuel, Temp, Flow gauges all work, the AMPs show zero.
This suggests many instruments do not check the electrical properties.
The a/c engine turns over and works fine without a battery or
alternator (magneto?).
I am unsure how the output properties are affected by switches or if
they can be.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 8, 2005 10:15 am, Karsten Krispin wrote: Is it possible that you have a manual of the Airbus, or from where do you get your ideas? I don't have any manual on Airbus. I wish I have. There are some books in my university's library, as well as some online references to help me script the FBW system. Unfortunately, I haven't got a chance to use them yet. Because the Airbus-System are working intern more or less in the same way. Type-Rating issue on so on... So, I thought we first write a core. That one could be extended on one hand to an A32X/330/340- and on the other hand to an A380 cockpit. Here, a manual could be helpfull. While commonality is a well-known strong point of Airbus, it cannot be applied to the fly-by-wire system. The aerodynamic properties of each family of aircraft is different, as do the flight control systems. Even the fly-by-wire system is different on each family: the A32X have special computers dedicated to each FCS-related task, while the A33X/A34X have integrated some of these computers into one unit. The A380 has even more integration in its fly-by-wire system than the former other families. You can't use a fly-by-wire system from one aircraft and expect it will work on another. I also got an answer from Steve Knoblock. He said, as you assumed as well, that the XML-Instruments are the one displayed in an 3D-Cockpit. Now there is still one point: When programming an FMC and the to this according Navigation Display, we need a possibility to spawn objects on runtime to place Waypoints in it and connect them and so on. Is there a way like in HTML with JavaScripts DOM? Not that I know of. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] c172: realism of radio transmission vs ambient noise volume
Sorry I haven't gotten to mention this before, since this is smth that I kept noticing for months already. In the c172 aircraft, the ambient noise in the cockpit is pretty similar to what one hears w/o any headset. When one turns the radio on and tries to hear the ATIS, it sounds pretty low volume. In real life, you can either put the radio on the loudspeaker (overhead), or put on the headset and have the radio in it. In the former case, I believe the volume is higher than this produced by fgfs. In the latter, I believe the radio volume is just about right, yet the ambient noise is much less because it is reduced by the headsets. For a quick fix, I suggest just increasing the relative volume of the nav/comm radios vs the ambient noise. (For full emulation, one could emulate donning headsets w/ different noise reduction/active noise cancelling frequency-based charachteristics, but this is pretty much an overkill, esp. since we don't even have a volume control on the comm radios). FYI: I'm talking about 0.9.8 on Debian Linux 2.6.8-2, ALSA snd_intel8x0 sound. I'm building a CVS version right now, and will post if that behaves any differently. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
