Re: [Flightgear-devel] glass panel instruments
On Sat 9. November 2002 22:19, you wrote: Jason Viloria wrote: Can anyone please tell me the state(or existence) of development on glass panel cockpit instruments on flightgear please. There's nothing working inside of FlightGear for this yet, but the OpenGC project (www.opengc.org) is available as a stand-alone app. You run it on a separate display, and it hooks to FlightGear over a socket. It's a little heavyweight for a direct port into FlightGear (right now, anyway, give the hardware a year or so to catch up), but would certainly be something you'd want to look at. I know I'd like to see something available for use in panel. Maybe not the full-on EFIS deck, but a digital AI or HSI would be great. Andy I made some experiments to implement GC to flightgear 2D panel, but stop when David independently said that technics I am using shouldn't be used. (Changing of viewport in middle of rendering). There was also a big problem with drawing simple lines. IMHO the way which to go is predraw GC screen to 2D texture in openGL 2D mode and then simply draw it as textured layer. Regards, 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] Fokker Dr.1 model added
At 11/10/02, Jon Berndt wrote: Michael: What are your design references for the two WWI aircraft? Do you mean how did I get the aero data? Regards, Michael Yes, and any other information used to model them. Jon smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] tail scraping the 747
The origin location on the 747 and a4 were fixed (Andy?) as of yesterday. Now you will note that the B747-400 on take off, rather than yanking back on the stick you need to just bring the nose up a bit and let it lift off, lest the aft section of the fuselage scrapes on the pavement...just like the real thing. Hmmm...anyone have a sound effect for that? :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
At 11/10/02, Michael Selig wrote: At 11/10/02, Jim Wilson wrote: Hi Michael, What a great addition to the fleet! Beautiful 3D model too. Would you or A.F. Scrub mind if I converted that to ac3d? The purpose would be to convert the textures to rgb, alpha the prop disk, animate, and add 3D instrumentation similar to the j3cub (which would involve a few cockpit geometry adjustments). This might be a few weeks away, but thought I'd ask. Best, Jim I'd be thrilled to see what you could do to improve the 3D model. I'll check w/ AF Scrub. Regards, Michael On this topic, AF Scrub has replied: It's with great pleasure that I see other people interested in my Camel. Of course it would be very nice that Jim makes improvements to my model. Personally I would be very happy if I could use a still better looking model with moving parts in CFS1 and CFS2 and in Flight simulator 2002. When Jim enhances the plane, could he please think about it ? Regards, Michael Michael Selig [EMAIL PROTECTED] said: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. I've included a blurb about the initial motivation for this model as it relates some work for the Discovery Channel. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker Dr.1 model added
I read somewhere that the aircraft was very sensitive to cross winds and would weather vane on the mearest whisper of such. Regards, Charlie H. Michael Selig wrote: I have just added the Fokker Dr.1 triplane to the CVS. There are notes in the readme below about how to get a 3D model file. Unfortunately, I could not acquire one under the GNU GPL. If I were going to be in a dog fight and had my pick of the Camel or Dr.1, the Dr.1 would be the weapon of choice. The Red Baron once said it It climbed like a monkey and maneuvered like the devil. I concur. Regards, Michael pre == = Fokker Dr.1= = WWI Fighter= = for FlightGear with LaRCsim and the UIUC Aeromodel = == = Flight model by: = = Michael Selig, et al. ([EMAIL PROTECTED]) = = http://www.aae.uiuc.edu/m-selig/apasim.html= == To run, try: fgfs --aircraft=fkdr1-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: fkdr1-v1-nl-uiuc-set.xml fkdr1/Sounds/uiuc/fkdr1-sound.xml UIUC/fkdr1-v1-nl/aircraft.dat UIUC/fkdr1-v1-nl/CDfa-03.dat UIUC/fkdr1-v1-nl/CLfa-03.dat UIUC/fkdr1-v1-nl/Cmfa-03.dat UIUC/fkdr1-v1-nl/Cmfade-01.dat These files above come with the FlightGear base package. To add a 3D external model, read the file: ~/Aircraft/UIUC/beech99/README.beech99.html as an example to follow. A Fokker Dr.1 model file that does work is fokdr1m2.zip from http://www.flightsim.com. (The fuselage for this model is too wide in the cockpit region.) There are several variants of this which can also be used, namely these files: dr-1cfs.zip dr1mp98.zip dr1mpcfs.zip fkdr1blk.zip fokdr-15.zip ~~ Model description and updates: 11/10/2002 - First release: v1-nl * Motivation: FGFS and the UIUC aero model were used to develop flight models for both the Sopwith Camel and Fokker Dr.1 Triplane. These models were then used in another simulation with a collaborator, Brian Fuesz. In that simulation, guns, terrain, villages, multiple planes, etc were added to simulate the last flight of the Red Baron. This work was filmed for the Discovery Channel show Unsolved History: The Death of the Red Baron scheduled to first air Dec 18, 2002. * A weights and balance was performed to arrive at an allowable c.g. location and from that data, mass moments of inertia were calculated. * Lift, drag and pitching moment data is modeled from -90 to +90 deg. Because the aerodynamics are not modeled from -180 to +180 deg, the aircraft will sometimes twitch when coming out of a tail slide as it passed through 90 deg. * In general, the aerodynamics are modeled using various sources. * Apparent mass effects are modeled. * Gyroscopic forces caused by engine rotation and aircraft rotations are modeled. For an animation of how a WWI-type rotary engine works, go here:http://www.keveney.com/gnome.html An example of gyroscopic forces, are those forces produced when one tries to rotate by hand a spinning bicycle wheel. * Spin aerodynamics are not yet modeled. * The simulation starts on the ground. Throttle up to take off or alternatively, use Ctrl-U to jump up in 1000-ft increments. * The Fokker Dr.1 did not have brakes. Application of brakes in FGFS will cause the aircraft to promptly nose over. (I have added a fake contact point ahead of the aircraft to avoid completely tipping over.) The c.g. of the aircraft sits almost directly above the wheel contact point. There is a reason for this. The aft fuselage and tail were designed to be very light. Thus, the tail could not support much load, so the weight of the aircraft largely rests on the main wheels, which again requires the c.g. to be almost directly above the wheels. * WWI aircraft engines did not have a conventional throttle (at least most did not). The engines were either on or off/idle using a blip-throttle. So it is not realistic to fly with a variable throttle, which the current model allows. * To modelers, I can provide a graphic showing the c.g. location. * Something I have not yet modeled is rudder ineffectiveness on roll out and touch down. When the aircraft is sitting on the wheels and tail skid, the angle of attack of the wing is so high that it is mostly stalled and the flow off the aft fuselage is also not well behaved. The result is that there is not much dynamic pressure (flow speed) on the vertical stabilizer, so there is little rudder authority in this condition. As a point of interest, why would the designers settle for this result? It's because of the rotary engine. The max speed is limited to 1200 rpm because of the
[Flightgear-devel] ANN: new aircraft aliases and 'include' attribute
I've introduced an aliasing arrangement into $FG_ROOT/Aircraft/, so that we can use simpler identifiers, and so that JSBSim isn't treated differently from other FDMs. Here's an example: --aircraft=c172 is now an alias for --aircraft=c172r which is an alias for --aircraft=c172r-jsbsim If, in the future, we happened to prefer the UIUC or YASim c172r as the default, we could simply change --aircraft=c172r to be an alias to --aircraft=c172r-yasim etc. This change depends on my patch to SimGear this morning to allow the 'include' attribute on the root element of an XML config file. You'll have to update to the latest SimGear CVS and make sure FlightGear is relinked with it. The main user-visible benefit is shorter names, like fgfs --aircraft=dc3 or fgfs --aircraft=sopwithCamel This also means that we can create new *-set.xml files by subtyping existing ones. For example, if someone made a DC-3 model for JSBSim, we could subclass the YASim config file like this: ?xml version=1.0? PropertyList include=dc3-yasim-set.xml sim descriptionDC-3 (JSBSim)./description flight-model archive=yjsb/flight-model /sim /PropertyList All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tail scraping the 747
Jim Wilson wrote: The origin location on the 747 and a4 were fixed (Andy?) as of yesterday. Yeah, that was me. I still say that the origin should be on the airframe instead of inside the plane, but a promise is a promise. :) Random note: how hard would it be to get the checkin account added to the base package CVS emails, like is done for FlightGear and SimGear? Sometimes you can tell who made the modifications by context, but often it's no so clear. Other good stuff, for people who haven't flown the 747 recently, is that the recent ground effect fix makes landing behavior much nicer. When flown in on a 3° glideslope*, the aircraft just barely levels out in ground effect. You have to decrease power (or push the nose down) very gently to get it on the ground; it's very easy to miss the touchdown point and land long. This sorta feels right to me, based solely on passenger seat observations. * I find that about 8° of AoA for approach is about right. At the default weight, this results in about a 150 knot approach; dunno if that's right or not. I haven't been able to find a good reference for approach numbers for the 747. I'd be happy to tune it for different numbers if someone has them. Now you will note that the B747-400 on take off, rather than yanking back on the stick you need to just bring the nose up a bit and let it lift off, lest the aft section of the fuselage scrapes on the pavement...just like the real thing. Hmmm...anyone have a sound effect for that? :-) To be fair, the tail has always been scraping inside the FDM. It's just obvious now that's what is happening. Before, it looked like you were running out of elevator authority. And I agree, a scraping sound would be really nice ear candy, and very easy to implement. I can just set a /sim/fuselage-contact boolean whenever one of the non-gear contact points is touching the ground. 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] Re: data logging
Let me try UFO and magic again. They did not back up when I tried them before, which is why I added the Skyhook, but maybe my joystick properties were screwed up. Mark -Original Message- From: Melchior FRANZ [mailto:a8603365;unet.univie.ac.at] Sent: Saturday, November 09, 2002 12:35 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: data logging * Julian Foad -- Saturday 09 November 2002 19:11: Boslough, Mark B wrote: 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). Have you tried --fdm=ufo? It can go backwards. And so does the magic carpet. m. ___ 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] Fokker Dr.1 model added
At 11/11/02, you wrote: I read somewhere that the aircraft was very sensitive to cross winds and would weather vane on the mearest whisper of such. Regards, Charlie H. That's true, and most of the WWI aircraft suffered from this type of problem. Most WWI airfields were circular or square so that pilots could always take off into the wind to avoid the cross wind problem. Regards, Michael Michael Selig wrote: I have just added the Fokker Dr.1 triplane to the CVS. There are notes in the readme below about how to get a 3D model file. Unfortunately, I could not acquire one under the GNU GPL. If I were going to be in a dog fight and had my pick of the Camel or Dr.1, the Dr.1 would be the weapon of choice. The Red Baron once said it It climbed like a monkey and maneuvered like the devil. I concur. Regards, Michael pre == = Fokker Dr.1= = WWI Fighter= = for FlightGear with LaRCsim and the UIUC Aeromodel = == = Flight model by: = = Michael Selig, et al. ([EMAIL PROTECTED]) = = http://www.aae.uiuc.edu/m-selig/apasim.html= == To run, try: fgfs --aircraft=fkdr1-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: fkdr1-v1-nl-uiuc-set.xml fkdr1/Sounds/uiuc/fkdr1-sound.xml UIUC/fkdr1-v1-nl/aircraft.dat UIUC/fkdr1-v1-nl/CDfa-03.dat UIUC/fkdr1-v1-nl/CLfa-03.dat UIUC/fkdr1-v1-nl/Cmfa-03.dat UIUC/fkdr1-v1-nl/Cmfade-01.dat These files above come with the FlightGear base package. To add a 3D external model, read the file: ~/Aircraft/UIUC/beech99/README.beech99.html as an example to follow. A Fokker Dr.1 model file that does work is fokdr1m2.zip from http://www.flightsim.com. (The fuselage for this model is too wide in the cockpit region.) There are several variants of this which can also be used, namely these files: dr-1cfs.zip dr1mp98.zip dr1mpcfs.zip fkdr1blk.zip fokdr-15.zip ~~ Model description and updates: 11/10/2002 - First release: v1-nl * Motivation: FGFS and the UIUC aero model were used to develop flight models for both the Sopwith Camel and Fokker Dr.1 Triplane. These models were then used in another simulation with a collaborator, Brian Fuesz. In that simulation, guns, terrain, villages, multiple planes, etc were added to simulate the last flight of the Red Baron. This work was filmed for the Discovery Channel show Unsolved History: The Death of the Red Baron scheduled to first air Dec 18, 2002. * A weights and balance was performed to arrive at an allowable c.g. location and from that data, mass moments of inertia were calculated. * Lift, drag and pitching moment data is modeled from -90 to +90 deg. Because the aerodynamics are not modeled from -180 to +180 deg, the aircraft will sometimes twitch when coming out of a tail slide as it passed through 90 deg. * In general, the aerodynamics are modeled using various sources. * Apparent mass effects are modeled. * Gyroscopic forces caused by engine rotation and aircraft rotations are modeled. For an animation of how a WWI-type rotary engine works, go here:http://www.keveney.com/gnome.html An example of gyroscopic forces, are those forces produced when one tries to rotate by hand a spinning bicycle wheel. * Spin aerodynamics are not yet modeled. * The simulation starts on the ground. Throttle up to take off or alternatively, use Ctrl-U to jump up in 1000-ft increments. * The Fokker Dr.1 did not have brakes. Application of brakes in FGFS will cause the aircraft to promptly nose over. (I have added a fake contact point ahead of the aircraft to avoid completely tipping over.) The c.g. of the aircraft sits almost directly above the wheel contact point. There is a reason for this. The aft fuselage and tail were designed to be very light. Thus, the tail could not support much load, so the weight of the aircraft largely rests on the main wheels, which again requires the c.g. to be almost directly above the wheels. * WWI aircraft engines did not have a conventional throttle (at least most did not). The engines were either on or off/idle using a blip-throttle. So it is not realistic to fly with a variable throttle, which the current model allows. * To modelers, I can provide a graphic showing the c.g. location. * Something I have not yet modeled is rudder ineffectiveness on roll out and touch down. When the aircraft is sitting on the wheels and tail skid, the angle of attack of the wing is so high that it is mostly stalled and the flow off the aft fuselage is also not well behaved. The result is that there is not much dynamic pressure (flow speed) on the vertical stabilizer, so
[Flightgear-devel] Re: data logging
* Boslough, Mark B -- Monday 11 November 2002 18:56: Let me try UFO and magic again. They did not back up when I tried them before, which is why I added the Skyhook, but maybe my joystick properties were screwed up. It's the fire button that makes you go backwards in both FDMs. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tail scraping the 747
Andy Ross wrote: Jim Wilson wrote: Now you will note that the B747-400 on take off, rather than yanking back on the stick you need to just bring the nose up a bit and let it lift off, lest the aft section of the fuselage scrapes on the pavement...just like the real thing. Hmmm...anyone have a sound effect for that? :-) To be fair, the tail has always been scraping inside the FDM. It's just obvious now that's what is happening. Before, it looked like you were running out of elevator authority. And I agree, a scraping sound would be really nice ear candy, and very easy to implement. I can just set a /sim/fuselage-contact boolean whenever one of the non-gear contact points is touching the ground. To be honnest, I don't think anyone would even notice if the Boeing were tail scraping over the runway. For example, it is very comon for F-16 to hit the runway with their ventral fins on startup or touchdown. This is usually only noticed afterwards by the groud crew. On a side note, it would be nice to make a distinction between locations that would crash the aircraft (nose, wing tips) and part that just cause the aircraft to clip to the ground (belly, ventral fins). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: new aircraft aliases and 'include' attribute
David Megginson wrote: etc. This change depends on my patch to SimGear this morning to allow the 'include' attribute on the root element of an XML config file. This also means that we can create new *-set.xml files by subtyping existing ones. For example, if someone made a DC-3 model for JSBSim, we could subclass the YASim config file like this: ?xml version=1.0? PropertyList include=dc3-yasim-set.xml sim descriptionDC-3 (JSBSim)./description flight-model archive=yjsb/flight-model /sim /PropertyList Excellent addition, this gives a lot of flexibillity for designers and end-users. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Skyhook (was data logging)
Thanks for letting me know. I had to look at the code to see how to back up. Now that I know how, I can do it. Skyhook operates a bit more like a crane, where the joystick axes control everything. Instead of toggling a switch like ufo and magic carpet, you do it with the yoke. This requires that you slow down and stop before backing up instead of slamming from v to -v (infinite accelerations seem a bit unnatural, even for UFOs and Magic Carpets). If you want Skyhook I have it. Mark -Original Message- From: Melchior FRANZ [mailto:a8603365;unet.univie.ac.at] Sent: Saturday, November 09, 2002 12:35 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: data logging * Julian Foad -- Saturday 09 November 2002 19:11: Boslough, Mark B wrote: 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). Have you tried --fdm=ufo? It can go backwards. And so does the magic carpet. m. ___ 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] tail scraping the 747
Erik Hofman wrote: To be honnest, I don't think anyone would even notice if the Boeing were tail scraping over the runway. For example, it is very comon for F-16 to hit the runway with their ventral fins on startup or touchdown. This is usually only noticed afterwards by the groud crew. True enough. But certainly some airframe touch situations are easily noticeable. Hauling back on the yoke of a 747 at 100 knots during a takeoff roll is guaranteed to be noticed, for example. :) I think, on the whole, a scraping sound would add more to the simulation experience than it takes away. Right now, it's very much non-obvious to the user when they've clipped a wing tip or tail. I think there's a training benefit to the sound, even at the expense of pure realism. On a side note, it would be nice to make a distinction between locations that would crash the aircraft (nose, wing tips) and part that just cause the aircraft to clip to the ground (belly, ventral fins). This is already done, in a sense. A crash is something that's able to force a gear or contact point through the ground plane. If this doesn't happen, then the contact was light enough not to bend the airframe (for some only vaguely plausible definition of bend, of course). There's really nothing special about the nose, for example. Light contact to the nose isn't going to kill the aircraft. The only reason it looks special is that, aerodynamically, you can't put the aircraft into a situation where a nose touch is light. :) 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
[Flightgear-devel] Re: Skyhook (was data logging)
* Boslough, Mark B -- Monday 11 November 2002 19:20: This requires that you slow down and stop before backing up instead of slamming from v to -v (infinite accelerations seem a bit unnatural, even for UFOs and Magic Carpets). Why don't you simply try it?! The UFO has no infinite acceleration. It brakes and then accelerates in the other direction. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tail scraping the 747
On Mon, 11 Nov 2002 10:35:25 -0800, Andy Ross [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I think, on the whole, a scraping sound would add more to the simulation experience than it takes away. Right now, it's very much non-obvious to the user when they've clipped a wing tip or tail. I think there's a training benefit to the sound, even at the expense of pure realism. ..is it possible to get the real thing off a black box tape? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Fokker Dr.1 model added
At 11/11/02, Jon Berndt wrote: At 11/10/02, Jon Berndt wrote: Michael: What are your design references for the two WWI aircraft? Do you mean how did I get the aero data? Regards, Michael Yes, and any other information used to model them. Jon Your word design threw me. I don't do any design when it comes to building a model; I do a lot of analysis and some estimation. The result is an engineering model, not a tuned model, albeit I might have to settle for some placeholders pending more discovery. The first step is to gather all relevant data that I can find, e.g. 3-views, controls surface throws, mass data on a component-by-component basis, performance and handling data, etc. After doing this, things will be missing. But it's like a puzzle w/ parts missing and you start putting things together. It's hard at first, then things start falling in place. As for missing data, in the end (if I pick the right kind of airplane for which there is a lot of data) I can make some reasonable estimates and do sanity checks. Ultimately, things come into focus. It helps being a pilot and an aerospace engineer/prof. When it's all done, you could call it reverse engineering. That's the answer in broad stroke. Details are taking all the mass data, and coming up w/ the moments of inertia. In the process I can find the c.g. and compare that w/ what it should be (or what I think it should be). I might have to move some parts around to get it all to work out, but to my surprise I am usually within 1-3 inches of the proper c.g. on the first pass. I keep track of all this in a spreadsheet. Then I start working out the aero data using many sources: background knowledge, NACA/NASA reports and others, books (e.g. Roskam's and specialized books on particular aircraft), and then several analysis codes (e.g. Cmarc/Pmarc, XFOIL and things I have written). One area of focus for me is the nonlinear aero data so that things like stall, hammer heads, tail slides, etc are mostly right (especially so w/ the ASW-20). Since I've been doing aero work (largely design related: aircraft, wind turbines, motorsports, yachts, etc), I have a good handle on getting things close and/or close enough. In this step I am mostly using linux (Fortran, Matlab, and specialized codes). Some important effects that I include: [1] model data over a wide range, e.g. +-90 or 180 deg and [2] apparent mass effects (important for low wing-loading aircraft). I have David Megginson to thank for the uiuc gear modeling code. In FGFS, I put gear and other contact points where they're supposed to be w/ reasonable spring constant and damping data, and it works! The ground-reaction behavior of the ASW 20 is amazing to me. I am weak on the engine data, focusing more on aero. Lately the engine is tuned so that I at least get the max rate of climb and max speed right. I have a model thrust curve that I tweak to nail down these points and others if I can get them. It's a 90% estimate for now, and admittedly it is one area where I do tune things. For the ASW 20, my estimate of zero thrust is 100% right! I am weakest on the 3D external visual model. In this area, thanks to open source projects like this, amazing things happen! I've been picking aircraft carefully and strategically. * The Airwave-like hang glider was picked because I wanted to try and model the flare on landing. This really soft flare is a consequence of apparent mass effects, which I included. Also, I've always wanted to fly a hang glider, but those are dangerous as my dad explained back in the 1970s. He was an actuary and knew the poor statistics. * I picked the Wright Flyer because there is some wind tunnel data as a starting point, and of course the centennial is nearly upon us. After I started working on the Flyer, I became aware that MSFS will be coming out w/ a special shrink-wrapped special edition Wright Flyer model. * The WWI aircraft are interesting because of the biplane and triplane wings as well as the gyroscopic forces from the engine. Apart from that, they're simple, not very sophisticated fighting machines relative to a F15. It helped to have some motivation from the Discovery Channel. * The ASW 20 was picked because I am a sailplane pilot, and the engine was out of the picture so doing the aero right would pay more dividends (no engine effects to mess things up). * My next aircraft is the Extra 300s aerobatic airplane. I like watching all the weird things aircraft can do in flight. This one will be a challenge! * There's also icing. Flying in icing conditions is simply not safe. One can envision ways of giving the pilot more information in the cockpit to make it safer. That's what we're doing in a nutshell. There's been no premeditated strategy to pick MSFS aircraft --- Sopwith Camel, Extra 300s, Wright Flyer. But it does provide an interesting basis for comparison. Regards, Michael
Re: [Flightgear-devel] New (UIUC) aircraft
At 11/11/02, you wrote: Hi, Just a short notice for aircraft developers, by adding the description tag to the *-set.xml files it is possible for users to see a short discription of each aircraft when invoking the --show-aircraft option at startup. In the future I think the description tag would be the only one displayed in the new (aircraft selection) GUI system. Erik Good to know. Thanks. Regards, Michael ___ 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] Re: Skyhook (was data logging)
I DID try it, but I do stand corrected. Not infinite, but with a high enough acceleration to plaster an earthling pilot to the inside of the windshield like an insect. Kinda like cruising along in a car and shifting from overdrive into reverse. But UFO transmissions are probably made from some advanced materials that can take this kind of abuse, so I'm o.k. with it. -Original Message- From: Melchior FRANZ [mailto:a8603365;unet.univie.ac.at] Sent: Monday, November 11, 2002 11:40 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: Skyhook (was data logging) * Boslough, Mark B -- Monday 11 November 2002 19:20: This requires that you slow down and stop before backing up instead of slamming from v to -v (infinite accelerations seem a bit unnatural, even for UFOs and Magic Carpets). Why don't you simply try it?! The UFO has no infinite acceleration. It brakes and then accelerates in the other direction. m. ___ 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] tail scraping the 747
Andy Ross [EMAIL PROTECTED] said: can just set a /sim/fuselage-contact boolean whenever one of the non-gear contact points is touching the ground. Sure, if you want to do that I'll figure out a sound to use. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tail scraping the 747
Erik Hofman [EMAIL PROTECTED] said: To be honnest, I don't think anyone would even notice if the Boeing were tail scraping over the runway. It probably doesn't happen much. But if you were to drop it down hard you might feel it if not hear it, and you might even hear the passengers in the way back start screaming. An old unix text based 747 flight simulator I liked to play with years ago considered tail scraping on take off or landing a crash, and it would stop and beep. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sopwith Camel model added
Michael Selig [EMAIL PROTECTED] said: On this topic, AF Scrub has replied: It's with great pleasure that I see other people interested in my Camel. Of course it would be very nice that Jim makes improvements to my model. Personally I would be very happy if I could use a still better looking model with moving parts in CFS1 and CFS2 and in Flight simulator 2002. When Jim enhances the plane, could he please think about it ? Cool. Well, I might be able to honor his request if someone wants to buy me the software :-) The last time I bought Flight Simulator it was on 5 1/4 floppies. Might have even been before Microsoft bought it. I'll go on record now predicting that Microsoft will find itself needing to support FlightGear's format (whatever that is) by the year 2012. Maybe I should send them a note so they don't get caught off guard. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] animation and gmax
Two Microsoft model file questions: Most all new (and several old) Microsoft-type models have movable surfaces. Is there a way to look at the *.mdl file or another and figure out what hooks need to go in fgfs/xml to drive those surfaces? Second, several of the MSFS models will not work w/ fgfs/plib, such as those files in newer gmax format. Might anyone know if and when plib might support the new files? Thanks, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS gripes
Hi all, I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: cvs server: Updating src-libs U src-libs/.cvsignore U src-libs/Makefile.am U src-libs/metakit-2.4.3-33.tar.gz U src-libs/zlib-1.1.4.tar.gz U src-libs/zlib.dsp and goes no further. I have no problems updating the fgfsbase or FlightGear CVS. I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause some unpredictable behaviour in the past. I don't usually have any problems so I just wanted to check with you guys before looking over my box. Many thanks, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS gripes
On Mon, 11 Nov 2002, Matthew Law wrote: I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: Try it as root. Every time that's happened to me, running as root has completed it, where running it again as my normal user has caused it to hang in exactly the same place. I suspect some sort of permissions problem somewhere, but I've never taken the time to work out where. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS gripes
On 11/11/02 at 9:38 PM Matthew Law wrote: Hi all, I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: cvs server: Updating src-libs U src-libs/.cvsignore U src-libs/Makefile.am U src-libs/metakit-2.4.3-33.tar.gz U src-libs/zlib-1.1.4.tar.gz U src-libs/zlib.dsp and goes no further. I have no problems updating the fgfsbase or FlightGear CVS. I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause some unpredictable behaviour in the past. I don't usually have any problems so I just wanted to check with you guys before looking over my box. Given that src-libs/zlib.dsp is the very last file to be updated, and that you don't really need it to be updated anyway if you've already installed zlib, I would think it would be fine simply to hit ctrl-c when it gets stuck at this point and assume that SimGear itself has updated fine. FWIW, I also sometimes see this hang-up behaviour at the end, but so far only when using compression. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Skyhook (was data logging)
* Boslough, Mark B -- Monday 11 November 2002 20:50: I DID try it, but I do stand corrected. Not infinite, but with a high enough acceleration to plaster an earthling pilot [...] Yeah, it's designed for extraterrestrials. Making it softer would have defeated the purpose of the UFO as a 3D cursor---to read out lat/lon coordinates and place objects etc. Maybe one could/should tune it so that it makes for a better compromise between realism and usability. m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fokker Dr.1 model added
On Mon, 11 Nov 2002 12:01:51 -0600, Michael Selig [EMAIL PROTECTED] wrote: At 11/11/02, you wrote: I read somewhere that the aircraft was very sensitive to cross winds and would weather vane on the mearest whisper of such. Regards, Charlie H. That's true, and most of the WWI aircraft suffered from this type of problem. Most WWI airfields were circular or square so that pilots could always take off into the wind to avoid the cross wind problem. Basically a WWII Fighter is an (underpowered) Ultra/Microlight The other great problem they had was loss of fabric or entire surfaces at high speed, especially in manoeuvre. The Dr. 1 was apparently very prone to loosing a wing when pulling out of a dive - something that was a rare event on the very similar[1] Sopwith Triplane. They were _very_ maneuverable though. Allegedly you could do a 180+ turn of under 50ft diameter (with great loss of 'energy') in most. Any chance of an SE5a[2]? The great, often ignored, usually severely underestimated, competitor to the Camel was designed and, initially, built at the Royal Aircraft Factory, Farnborough, on a site a short walk from my office. And when the 'Flyer' is finished, how about 'Army Aeroplane No.1'? Designed, built and flown by American born Mr Samuel F Cody it made the first sustained powered flight in Britain on 16th October 1908 at the same location. These people will have the details... http://www.fasta.freeserve.co.uk/index.htm Rick [1] Its alleged that the Dr.1 was in fact a re-engineered Tripe, based on a crashed example. The greatest change was the doubling of the armament from 1 to 2 MG. -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sound vol/pitch transforms are like panel x/y/r transforms
Fg_sound.cxx implements a way to control the volume and pitch of a sound specified in an XML config file. The optional steps in the volume control group are (and the pitch group is the same): - A variable value: one of A named property An internal special value (e.g. time since the sound started) - Transformed by a function: one of Inverse Absolute Square root Logarithm - Scaled by a (constant) factor - Clamped to (constant) max and min - Added to a (constant) offset These all have sensible (no-change) defaults (except for anomaly 1 below). This group can be repeated; the results are multiplied together except for the offsets which are all added afterwards. Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. The instrument panel transformations (x-offset, y-offset, rotation) have these optional steps: - A variable value: A named property - Transformed by: An interpolation table - Clamped to (constant) max and min - Scaled by a (constant) factor - Added to a (constant) offset These all have sensible (no-change) defaults. This group cannot be repeated. Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: - Leave the handling of the internal special values in the sound module, or find a way to present them as properties. - Add the Interpolate option to the list of functions (Inverse etc.). - Swap the order of Scaling and Clamping in (probably) the sound module (because there are fewer uses there). - Lose the pitch offset bug and the negative scaling factor hack. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is needed, a general expression evaluator would be better than providing one specific way to combine sub-expressions. For example, I would like to be able to use property values for the things that currently have to be constants. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 747 question
Andy, Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) This looks odd from an external view standpoint. It seems like we'd want a slight amount of positive alpha, but I couldn't find alpha in the property tree? 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] 747 question
Curtis L. Olson wrote: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) This looks odd from an external view standpoint. It seems like we'd want a slight amount of positive alpha, but I couldn't find alpha in the property tree? The angle of attack property is available as /velocities/alpha-deg. No, I don't know why it's under velocities, either. :) One thing to point out is that FL180 is a very low cruise altitude, and 490 knots indicated (you are quoting IAS off the HUD, right?) is a very high indicated airspeed. At this speed, the aircraft will be producing significantly more lift than it would at a normal cruise altitude of FL360. In order to keep the lift at 1G, the nose needs to point down more. Remember also that angle of attack is an arbitrary number. Zero AoA is almost never the same as the AoA of zero lift. In YASim's case, zero AoA is defined as the X axis direction. The point of zero lift depends on several factors, most importantly including the camber and incidence of the wing. So basically, you have the plane in an unusual flight environment. Real planes are almost never flying this fast at this altitude; they'll be at ~300 KIAS or so and using the extra available thrust for climbing. I really don't know what attitude real jet would have under these conditions. You can try playing with the camber attribute of the main wing (which defines the zero-AoA lift of the wing). If you reduce it, you'll get less lift at low angles of attack and thus require less nose-down attitude to get the same lift. This can have nasty interactions with the drag computation, though. I can at least say that YASim solves for a cruise AoA as part of initialization and prints it along with the rest of the report. In the solution cruise environment, it is flying with a slightly positive AoA: something like 2-3 degrees if I remember correctly. 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] CVS gripes
David Luff wrote: On 11/11/02 at 9:38 PM Matthew Law wrote: I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: cvs server: Updating src-libs U src-libs/.cvsignore U src-libs/Makefile.am U src-libs/metakit-2.4.3-33.tar.gz U src-libs/zlib-1.1.4.tar.gz U src-libs/zlib.dsp and goes no further. I have no problems updating the fgfsbase or FlightGear CVS. I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause some unpredictable behaviour in the past. I don't usually have any problems so I just wanted to check with you guys before looking over my box. Given that src-libs/zlib.dsp is the very last file to be updated, and that you don't really need it to be updated anyway if you've already installed zlib, I would think it would be fine simply to hit ctrl-c when it gets stuck at this point and assume that SimGear itself has updated fine. FWIW, I also sometimes see this hang-up behaviour at the end, but so far only when using compression. Yes, I find it's a compression problem too. I have compression set at the default in my ~/.cvsrc so I use cvs -z0 up to update FlightGear (source), SimGear and TerraGear (which are all on the same server and are the only projects with which I have this problem). I used to think it was CygWin-specific but it's just the same on Linux. So, if you're sure -z0 is in effect, I can confirm that hitting Ctrl-C works OK on a cvs update. However, doing a cvs diff blah.diff, Ctrl-C is not good: you lose the end of the diff file. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Julian Foad wrote: ... Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. It's not. It is a hack because the behaviour of the part is totally different from the rest. By this hack you would be able to start at the offset level and then scale down according to the property value and the factor. That's why 2. isn't correct either ... Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: - Leave the handling of the internal special values in the sound module, or find a way to present them as properties. The internal special values are releated to the current instance of the sound. I figure it would be pretty hard to turn them into properties. - Add the Interpolate option to the list of functions (Inverse etc.). - Swap the order of Scaling and Clamping in (probably) the sound module (because there are fewer uses there). - Lose the pitch offset bug and the negative scaling factor hack. It's not a bug. A value with a pitch of 0.0 would have a frequency of 0.0 which isn't allowed and can't be heard. It actually should be 1.0! - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is They are needed to add an envelope to the sound. It is for example possible to start playing a sound based on a property, and change it's behaviour based on another property (change it's pitch and/or volume). needed, a general expression evaluator would be better than providing one specific way to combine sub-expressions. For example, I would like to be able to use property values for the things that currently have to be constants. I'm not sure I understand what you mean by I would like to be able to use property values for the things that currently have to be constants, but the idea of creating a general expression evaluator seems good enough. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) Neh, better not. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] new 'v' view for preferences.xml
Hi All, I'd like to share w/ everyone a new view that is *extremely* useful I think. The view looks at the aircraft externally and always looks in a fixed direction so that when the aircraft yaws back and forth the view does not swing back and forth. This is especially useful for studying aircraft motions in aerobatic/wild maneuvers. Mousing around will change the view direction. Personally, I fly in this mode 99% of the time. Here's the xml code (a 5th view) that can be included in ~/fgfsbase/preferences.xml view nameChase View wo yaw/name typelookat/type config from-model type=boolfalse/from-model from-model-idx type=int0/from-model-idx eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path at-model type=booltrue/at-model at-model-idx type=int0/at-model-idx ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m x-offset-m type=double0/x-offset-m y-offset-m type=double0/y-offset-m z-offset-m type=double-25/z-offset-m /config /view Toggling 'v' eventually gets to this view. Rob Deters' came up w/ this, and I've been flying w/ it thinking that it was part of the fgfs cvs for all to use. Can this be added to the cvs fgfsbase package? I can add it. Any objections? Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new 'v' view for preferences.xml
ps In preferences.xml, the number of views also needs to be changed from 4 to 5: number-views type=int5/number-views At 11/11/02, you wrote: Hi All, I'd like to share w/ everyone a new view that is *extremely* useful I think. The view looks at the aircraft externally and always looks in a fixed direction so that when the aircraft yaws back and forth the view does not swing back and forth. This is especially useful for studying aircraft motions in aerobatic/wild maneuvers. Mousing around will change the view direction. Personally, I fly in this mode 99% of the time. Here's the xml code (a 5th view) that can be included in ~/fgfsbase/preferences.xml view nameChase View wo yaw/name typelookat/type config from-model type=boolfalse/from-model from-model-idx type=int0/from-model-idx eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path at-model type=booltrue/at-model at-model-idx type=int0/at-model-idx ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m x-offset-m type=double0/x-offset-m y-offset-m type=double0/y-offset-m z-offset-m type=double-25/z-offset-m /config /view Toggling 'v' eventually gets to this view. Rob Deters' came up w/ this, and I've been flying w/ it thinking that it was part of the fgfs cvs for all to use. Can this be added to the cvs fgfsbase package? I can add it. Any objections? Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Erik Hofman wrote: Julian Foad wrote: ... Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. It's not. It is a hack because the behaviour of the part is totally different from the rest. By this hack you would be able to start at the offset level and then scale down according to the property value and the factor. That's why 2. isn't correct either ... Not totally different. Quite similar. Have you looked at the code? The way I read it, a negative value causes the (scaled, clamped, etc.) value to be subtracted from the offset rather than added to it. That is exactly the same as just using a negative scaling factor. The only differences are: - For negative, you want the default offset to be 1; - For positive, you might want the default offset to be 1 or 0 depending on what you are doing! - When the subtraction is done it forgets any value generated by a previous volume group, which means it's only useful in the first group (e.g. the first volume transformation of potentially several volume transformations). OK, I did not notice the need for offset=1 in subtractions. However, this should be the case for volume just the same as for pitch. You don't want the volume to be subtracted from zero either. - Lose the pitch offset bug and the negative scaling factor hack. It's not a bug. A value with a pitch of 0.0 would have a frequency of 0.0 which isn't allowed and can't be heard. It actually should be 1.0! Offset=0 doesn't necessarily mean pitch=0. For example I want pitch=(K * propeller_rpm). When RPM=0 I don't care if pitch=0; I know it doesn't make sense, but volume will be zero too. Maybe the internal sound player algorithm will have to limit the minimum pitch to something other than zero, but that shouldn't stop me from requesting it to be as near as possible to zero. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is They are needed to add an envelope to the sound. It is for example possible to start playing a sound based on a property, and change it's behaviour based on another property (change it's pitch and/or volume). No, we could have that ability with one volume transformation and one pitch transformation per sound. (These are separate from the sound on/off property.) I'm asking whether we need more than one transformation of each type. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) Neh, better not. OK, I agree it's not as simple as I first thought. I'll think more carefully. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Luff wrote: On 11/10/02 at 4:02 AM Julian Foad wrote: Ah yes, starting, I seem to recall a lot of hacking and kludging to get everything to work :-) There's a number of problems currently: ... Have fun :-) Ah, glad you're there. If you're interested and have time to look, my current attempt is at http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff but, as I said, not finished. (Well, it will never be finished. I mean not completely satisfactory as a patch yet.) It removes some of the arbitrary bits - especially the non-linear bits like if RPM N then ... - and makes starting and idling nicer (especially at throttle less than the minimum allowed idle setting - it was fun running it below 500 RPM, on the unstable side of its power curve, after I put the friction always present but before I put the idle adjust constant in there). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Julian Foad wrote: Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: If you guys are thinking of changing the way we do linear function of a property value definitions in configurations, let me argue for a slightly different way to do it: The problem with specifying a multiplier (e.g. scaling or rotation) and an offset is that these two opperations don't commute. Especially when coupled with a syntax that is order-independant (you can *specify* the scaling last, but it still happens first, or vice versa) it's a constant confusion for the user as to what the final result will be, with the end result that the generated configurations are hacked up balls of goo. Be honest everyone: how many people have ended up typing random values into things like this trying to get the results they expect? I know I have. Instead, why not specify a range mapping. That is, input values in the range [a,b] get mapped linearly to output values in the range [c,d]. Input values outside of [a,b] can be clamped to that range before computation. This has a few advantages: + Out of bounds values are eliminated by the clamping step. This is especially useful for sounds, where beyond-maximum scaling factors cause distortion. + The offset and multiplier are specified simultaneously and implicitly, so the user doesn't need to remember any precedence rules. + No need to handle the mind-bending gymnastics involved in negative scaling factors if you want something to scale in the reverse direction. (Negative scaling factors invert the direction of the offset only if the offset comes last; no wait... you get the idea). This is the way that YASim handles its property input and output specifiers*, and it's worked pretty well. Take a look at the reaction jet definitions for the harrier for an example of how much complexity this can eliminate. Andy * albeit not in a standard way -- YASim doesn't use the property tree parser, since I didn't know about it. It uses the lower-level XML callback API. -- 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] new 'v' view for preferences.xml
Michael Selig [EMAIL PROTECTED] said: Toggling 'v' eventually gets to this view. Rob Deters' came up w/ this, and I've been flying w/ it thinking that it was part of the fgfs cvs for all to use. Can this be added to the cvs fgfsbase package? I can add it. Any objections? That sounds fine. We might want to use this as a replacement for the 4th view. The 4th view is a tower view that doesn't track the FDM location as the 3rd view does; that is, you can look around the airport with the mouse. Mostly that was something I threw in there as both a test and demonstration of the flexibility of the viewer config. I don't actually use it myself, and I'm not sure if anyone does. Just as an aside, it looks like there is a bug in the existing chase view. Haven't had a chance to nail it down, but the gist is the view angle seems to be affected by yaw if the view angle is not centered on the vertical axis to begin with (not in sensible controlled way, mind you). My plan is to put together and post a list of bugs that seem to have cropped up since the last release (maybe earlier) just to see if anyone knows what they might have changed to cause them. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
On Mon, 2002-11-11 at 15:12, Andy Ross wrote: Curtis L. Olson wrote: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) This looks odd from an external view standpoint. It seems like we'd want a slight amount of positive alpha, but I couldn't find alpha in the property tree? The angle of attack property is available as /velocities/alpha-deg. No, I don't know why it's under velocities, either. :) One thing to point out is that FL180 is a very low cruise altitude, and 490 knots indicated (you are quoting IAS off the HUD, right?) is a very high indicated airspeed. At this speed, the aircraft will be producing significantly more lift than it would at a normal cruise altitude of FL360. In order to keep the lift at 1G, the nose needs to point down more. FYI: 490 KIAS is way too fast for most big jets under *any* circumstances. Remember also that angle of attack is an arbitrary number. Zero AoA is almost never the same as the AoA of zero lift. In YASim's case, zero AoA is defined as the X axis direction. The point of zero lift depends on several factors, most importantly including the camber and incidence of the wing. So basically, you have the plane in an unusual flight environment. Real planes are almost never flying this fast at this altitude; they'll be at ~300 KIAS or so and using the extra available thrust for climbing. I really don't know what attitude real jet would have under these conditions. You can try playing with the camber attribute of the main wing (which defines the zero-AoA lift of the wing). If you reduce it, you'll get less lift at low angles of attack and thus require less nose-down attitude to get the same lift. This can have nasty interactions with the drag computation, though. I can at least say that YASim solves for a cruise AoA as part of initialization and prints it along with the rest of the report. In the solution cruise environment, it is flying with a slightly positive AoA: something like 2-3 degrees if I remember correctly. 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] 747 question
Curtis L. Olson [EMAIL PROTECTED] said: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) Wasn't sure but it sounds like you are using the autopilot's alitutde hold. Just to add to what Andy was saying, the altitude hold as currently implemented doesn't work realistically. If I'm not mistaken the 747 autopilot and autothrottle system should be holding the pitch at the preset angle for cruise with trim and the throttle should be controlling rate of climb/descent. You could try that method manually to see if it will trim. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
Tony Peden [EMAIL PROTECTED] said: FYI: 490 KIAS is way too fast for most big jets under *any* circumstances. Yes, there is a similar problem at mach 0.8 ~ 0.85 as well though. And IIRC at altitude as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tail scraping the 747
On Mon, 11 Nov 2002, Arnt Karlsen wrote: ..is it possible to get the real thing off a black box tape? I doubt it. In the only two cases that I know about (was not personally involved tho :-) ), no one in the cockipt heard anything at all. In one of the two nobody in the back did either! jj jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
For the 747-400 Va (Design maneuvering speed) is 330 kts at sl, 334 at 10k, 358/.92mach at 29,000 Vmo is 365 at sl, 316 at 35,000 On Tue, 12 Nov 2002, Jim Wilson wrote: Tony Peden [EMAIL PROTECTED] said: FYI: 490 KIAS is way too fast for most big jets under *any* circumstances. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 747 question
Curtis L. Olson writes: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) From what I can find, the 747 is supposed to be able to cruise at around 490 KTAS between FL280 and FL350. At FL280, 490 KTAS true would be about 314 KIAS; at FL350, it would be a bit lower, but you're getting near the tropopause and things get screwy. At FL180, 314 KIAS would give you only 427 KTAS. If you're trying to fly at 490kt *indicated* at FL180, then you're pushing something like 666kt true -- it would be no surprise that you'd have to push the nose down and abuse the engines to maintain that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
Andy Ross writes: So basically, you have the plane in an unusual flight environment. Real planes are almost never flying this fast at this altitude; they'll be at ~300 KIAS or so and using the extra available thrust for climbing. Counter-example: a few years ago, I flew from Ottawa to Heathrow direct in an Air Canada 747-400. It made a stop at Montreal Dorval to pick up more passengers before starting the transatlantic leg. CYOW to CYUL is about 85 nm, and we stayed below the flight levels for the whole way. Second counter-example: 767s often fly between Ottawa and Toronto (196 nm), usually no higher than FL180. Still, the point is valid -- a 747 doesn't cruise that fast at low altitudes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 747 question
David Megginson writes: If you're trying to fly at 490kt *indicated* at FL180, then you're pushing something like 666kt true -- it would be no surprise that you'd have to push the nose down and abuse the engines to maintain that. You also have to allow for compressibility effects in calculate TAS for something that fast -- that's not an issue with the spam cans I fly. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Latest CVS Crashes
I just updated from CVS for both the Mac and Windows and got the same error when I tried to run. The Mac traceback is as follows: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0006 Thread 0 Crashed: #0 0x000525f8 in ssgContext::forceBasicState() (ssgContext.cxx:103) #1 0x00038464 in ssgCullAndDraw(ssgBranch*) (ssg.cxx:273) #2 0x427c in fgRenderFrame() (main.cxx:2143) #3 0x6284 in fgMainLoop() (main.cxx:271) #4 0x90163888 in __CFRunLoopDoTimer #5 0x901493e0 in __CFRunLoopRun #6 0x9018157c in CFRunLoopRunSpecific #7 0x92ba34cc in RunCurrentEventLoopInMode #8 0x92bb32f4 in ReceiveNextEventCommon #9 0x92bda280 in BlockUntilNextEventMatchingListInMode #10 0x93082184 in _DPSNextEvent #11 0x930ccf84 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #12 0x930ca500 in -[NSApplication run] #13 0x94fd9110 in glutMainLoop #14 0x8c7c in mainLoop(int, char**) (main.cxx:1746) #15 0x8dd4 in main (main.cxx:1834) #16 0x2b5c in _start (crt.c:267) #17 0x29dc in start The error was in the same routine, so I am assuming that there is something uninitialized somewhere. The bad pointer was in slightly different lines of code, though: if ( ovState != NULL ) ovState - force () ; --- Windows Crashes else basicState - force () ; --- Mac Crashes Windows died where it did because ovState contained the Windows non-zero invalid pointer value (0xcacacaca). Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
