Re: [Flightgear-devel] ASW 20 model added
Michael, Very nice flyer, and it has a sharp 3d model too. This one should be a lot of fun for the glider enthusiasts. Now all we need to add is a real tow plane and thermals. :-) Curt. Michael Selig writes: I have just add an ASW 20 to the CVS. Not only does it include the flight dynamics model, but also there's an external model from Roland Stuck! He has granted permission for us to use and release these with FlightGear under the GNU GPL. Taken together, this is one really neat airplane in FGFS. There's a readme file on the external model from Roland Stuck in: ~/fgfsbase/Aircraft/asw20/Models/uiuc/asw20-stuck/ The flight model readme from ~/fgfsbase/Aircraft/UIUC/ is included below. Regards, Michael == = ASW 20 = = 15-meter class sailplane = = 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= == = External model by: = = Roland Stuck ([EMAIL PROTECTED]) = == To run, try: fgfs --aircraft=asw20-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: asw20-v1-nl-uiuc-set.xml asw20/Models/uiuc/asw20-stuck/asw20-stuck-model.xml asw20/Models/uiuc/asw20-stuck/asw20.mdl asw20/Models/uiuc/asw20-stuck/asw20mp_.0af asw20/Models/uiuc/asw20-stuck/asw20mp_.1af asw20/Models/uiuc/asw20-stuck/asw20mp_.2af asw20/Models/uiuc/asw20-stuck/asw20mp_.3af asw20/Models/uiuc/asw20-stuck/asw20mp_.4af asw20/Models/uiuc/asw20-stuck/asw20mp_.5af asw20/Models/uiuc/asw20-stuck/asw20mp_.6af asw20/Models/uiuc/asw20-stuck/asw20mp_.7af asw20/Models/uiuc/asw20-stuck/asw20mp_.8af asw20/Models/uiuc/asw20-stuck/asw20mp_.9af asw20/Models/uiuc/asw20-stuck/asw20mp_.aaf asw20/Models/uiuc/asw20-stuck/asw20mp_.baf asw20/Models/uiuc/asw20-stuck/asw20mp_.caf asw20/Models/uiuc/asw20-stuck/asw20mp_.daf asw20/Models/uiuc/asw20-stuck/asw20mp_.eaf asw20/Sounds/uiuc/asw20-sound.xml UIUC/asw20-v1-nl/CDfa-01.dat UIUC/asw20-v1-nl/CLfa-01.dat UIUC/asw20-v1-nl/Cmfa-01.dat UIUC/asw20-v1-nl/Cmfade-01.dat UIUC/asw20-v1-nl/aircraft.dat These files above come with the FlightGear base package. ~~ Model description and updates: 11/8/2002 - First release: v1-nl * Roland Struck ([EMAIL PROTECTED]) has granted FlightGear permission to use and release the external model files with FlightGear under the GNU GPL. * This flight dynamics model simulates an ASW 20 15-meter sailplane. * 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 -180 to +180 deg. In general, the aerodynamics are modeled using various sources too numerous to mention here. * Apparent mass effects are modeled. * The simulation starts on the ground. To simulate being tow, the throttle can be used. The thrust was tuned to simulate a reasonable line tension and max rate of climb while on tow. Alternatively, Ctrl-U can be used to jump up in 1000-ft increments. * Interesting flight characteristics to note: - When starting out, quickly change views to see the external aircraft. The wings will start out level, and then one side will drop. For whatever reason, the left wing drops first even though the data in the model is symmetrical. - Taking off requires careful control of the rudder and ailerons. Use rudder to line up with the runway and ailerons to level the wings. It is easy to over correct (especially without a headwind), and the consequences should be reminiscent of being towed in a real sailplane. [I am speaking from experience, being a sailplane pilot and having part owned a Pegasus (~ASW 19)]. - The max lift-to-drag ratio is approx 42:1. This means that from a height of 1 mile, the gliding distance is 42 miles. This efficiency is most readily apparent when flying and landing. Adding spoilers is a high priority for the next update. - The long wings produce an over banking tendency when circling as would be done in thermals. Top aileron is required to keep the wings from over-banking. In addition extra rudder is then required to stay coordinated. - Tail slides and hammer heads appear to be quite realistic. This is one bonus that comes from modeling key aerodynamic data from +-180 deg. * What is
Re: [Flightgear-devel] data logging
Boslough, Mark B wrote: O.K. I've got a couple of new FDMs. 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 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. Just want to check if you've done something that's already there. Hmm ... I see that it isn't mentioned in the --help. Ooops. But it does exist. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Dave Perry writes: The lights look great! Thanks. The rear facing white light on the rudder is switched on with the red and green wing tip lights as the nav lights. Is there a RearNavLightOn and RearNav LightOFF object name? I haven't got around to adding the rear light yet. 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] Yasim origin and model offsets
It seems that a while back this came up when I was working on the viewer or maybe tweaking the original 3D aircraft model rotations. After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). Anyway, what I now remember is this: the camera position as configured for the chase view is always in relation to the FDM location. And in the case of Yasim that location is always the nose. So if the nose goes up so does the camera. In the air, this gives the _appearance_ that the nose is stationary during a pitch, and the 3D aircraft model moves with a kind of a wagging motion rather than a pitching motion. I understand that the motion of the aircraft is correct and the 3D model moves correctly when it matches the FDM, the problem is the way it looks on the screen when the origin is at one end of aircraft. Also, a bug report, for some reason the model offsets (e.g. /offsets/x-m) appear to no longer work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
At 11/9/02, Jim Wilson wrote: It seems that a while back this came up when I was working on the viewer or maybe tweaking the original 3D aircraft model rotations. After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). Anyway, what I now remember is this: the camera position as configured for the chase view is always in relation to the FDM location. And in the case of Yasim that location is always the nose. So if the nose goes up so does the camera. In the air, this gives the _appearance_ that the nose is stationary during a pitch, and the 3D aircraft model moves with a kind of a wagging motion rather than a pitching motion. I understand that the motion of the aircraft is correct and the 3D model moves correctly when it matches the FDM, the problem is the way it looks on the screen when the origin is at one end of aircraft. Also, a bug report, for some reason the model offsets (e.g. /offsets/x-m) appear to no longer work. FWIW I have looked at the offsets before. At one point they did work w/ the UIUC models, but I think more recently (last 4-5 months) they stopped working w/ the UIUC models. However, at that time, they did work w/ the other models. So I speculate that the bug seems to be FDM specific. It *is* broken w/ the UIUC models. Regards, Michael Best, Jim ___ 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
[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
Re: [Flightgear-devel] Yasim origin and model offsets
Jim Wilson wrote: After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). Yeah, the nose gear compresses by 2m, which is too far. I got better results by changing to compression=1 in the nose gear definition. But with that change it ends up too stiff, and tends to end up in an undamped oscillatory bounce on its nose gear. I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. Anyway, what I now remember is this: the camera position as configured for the chase view is always in relation to the FDM location. And in the case of Yasim that location is always the nose. Oh, good point. This will create problems for view direction too -- the viewer will expect to rotate around the center of the aircraft instead of the nose. But there are other places in the code that make assumptions about the location of the aircraft, too, and they have different requirements. The tile rendering and navigation stuff obviously doesn't care about a few tens of meters, but the altitude computation in the HUD (which is different from the agl property) does, and it uses aircraft origin as well. Or consider an ILS receiver, which really wants to use the location of the antenna on the 747, not the cockpit, c.g., or center. (I have no idea where this is, but I suspect it's closer to the tail, so that the main gear are what travel down the exact glidepath). Maybe we need separate origin offsets for all of these applications? Actually, wouldn't a sane default for the view code be to *always* pick a center point for the offset? That is, just pick the center of a bounding box computed from the model (or the FDM). This will match more closely to what the user expects in all cases I can think of. That being said, I'd be happy to put this to rest right now by moving the YASim origin for the 747 and A-4. :) 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] Yasim origin and model offsets
Sigh ... I thought we had already solved this one http://www.menet.umn.edu/~curt/lists/fgfs/archive-200204/msg00176.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] glass panel instruments
Hi Can anyone please tell me the state(or existence) of development on glass panel cockpit instruments on flightgear please. I am quiet new to flightgear but not so new to Opengl and programming. I'd like to congratulate everyone on how great this project is. I wish I heard about it earlier. Jason __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
I wrote: I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. Well, that was easy enough. You can now use spring and damp attributes on gear objects to modify the default ones you get out of the solver. These are unitless scalars, specify 0.5 if you want half the damping coeffient, etc... I've checked this in, as well as a change to the 747 nose gear that fixes the wobble and bounce issues. Someone with more experience than I should try the result to see that I got it right. The nose gear now just barely bottoms out when you whip the nose down from a tail dragging situation with full braking and full down elevator, comes up but doesn't leave the ground, and oscillates once or twice. That seems like it would be the design goal for the real thing, but I dunno. Maybe it should have more bounce? Some of the other YASim planes could probably use some gear treatment too. The default damping is probably too stiff for the 172 and Cub, which have spring steel gear. 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] glass panel instruments
Jason Viloria [EMAIL PROTECTED] said: Hi Can anyone please tell me the state(or existence) of development on glass panel cockpit instruments on flightgear please. I am quiet new to flightgear but not so new to Opengl and programming. I'd like to congratulate everyone on how great this project is. I wish I heard about it earlier. Take a look at http://www.opengc.org, this will run in a seperate window or seperate computer and interface to FlightGear. Looks like this: http://www.flightgear.org/Gallery/Link/opengc-turning.html I've been pondering techniques for getting a partial implementation of a gc into FlightGear to be used for the 747-400 3D cockpit, (maybe based on the existing 2D panel or 3D modeling), but haven't come up with anything. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glass panel instruments
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 -- 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] Yasim origin and model offsets
Andy Ross [EMAIL PROTECTED] said: Actually, wouldn't a sane default for the view code be to *always* pick a center point for the offset? That is, just pick the center of a bounding box computed from the model (or the FDM). Not sure, but it would seem like the pitch axis would generally be somewhat near the wings, which aren't always centered. Note to readers: To save folks from pointing this out yet again, we all know c.g isn't a fixed location. That being said, I'd be happy to put this to rest right now by moving the YASim origin for the 747 and A-4. :) Maybe it would be most economical, calculation wise, to do it that way? In the model/view code we'd have to throw another offset in the mix. Best, Jim ___ 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 Megginson wrote: I like the idea as well: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs (let's try the J3 cub with 180HP). Unfortunately, the FDM people haven't been too enthusiastic: in particular, JSBSim is supposed to run standalone as well as inside FlightGear, so they need some kind of internal engine model. Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. While that's the sort of thing I do at work, I'm not yet in a position to do it here. As for the guts of how the engines are modelled ... I first worked on the starting and stopping behaviour of the JSBsim engine. The thermodynamic model of the engine is probably very good but there's lots of yucky stuff there to do with starting etc. I've done some stuff there, and in the sound configuration, but not finished. I'll go into that later. Then I looked at the YASim piston engine to see how that handles starting. Before I try to do anything in there I want to ask about some things (Andy?): 1. PistonEngine::calc says // Calculate manifold pressure as ambient pressure modified for // turbocharging and reduced by the throttle setting. According // to Dave Luff, minimum throttle at sea level corresponds to 6 // manifold pressure. Assume that this means that minimum MP is // always 20% of ambient pressure. (But that's too much idle // power, so use 10% instead!) But we need to produce _zero_ // thrust at that setting, so hold onto the output value // separately. Ick. _mp = pressure * (1 + _boost*(_turbo-1)); // turbocharger float mp = _mp * (0.1f + 0.9f * _throttle); // throttle _mp *= _throttle; What's that bit about the separate output mp? An engine doesn't produce zero thrust at idle, just a low thrust. And manifold pressure isn't supposed to be related to thrust in a simple way, is it? Sorry to peer into a nasty bit. The beauty of Open Source is ... we can see the whole thing, warts and all! :-) 2. At the end of the same function, _egt = corr * (power * 1.1f) / (massFlow * specHeat); if(_egt temp) _egt = temp; When I'm running this at idle, _egt comes out at 80 (kelvin); presumably this should be added to ambient temp (which is 288) rather than clamped to it: _egt = corr * (power * 1.1f) / (massFlow * specHeat); _egt += temp; 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. There is a negative torque added that should make it stop quickly, and I can't see what's wrong with it (that would have this effect). Actually, as acceleration of the engine is equally slow, perhaps the problem is in the transfer of the torque to the external propulsion system code - perhaps the wrong units? 4. That negative torque: Interpolate it away as we approach cruise RPMs, though, to prevent interaction with the power computations. Ugly. Actually, the only way the variable power is used after that point is to compute the EGT, and that wants to know thermally developed power anyway (i.e. excluding the starter motor contribution and the friction reduction) so that should be fine. I think it would be correct to subtract the torque loss at all speeds - in fact, more loss at higher speeds because of gas flow turbulence etc. By the way, the experimental values here were with j3cub-yasim because c172-yasim gives a solution failure for elevator. I have some local changes, but nothing in YASim or anything that I think could affect it - just in the JSBSim engine, sound handling, joystick, etc. For all this, my original aim was just to get simple things like a realistic cranking speed of about 100 RPM, and some rotation sound while the engine is spinning down after being switched off! - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sopwith Camel model added
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 == = Sopwith Camel F.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= == = External model by: = = A.F.Scrub Scrubby PC ([EMAIL PROTECTED]) = == To run, try: fgfs --aircraft=sopwithCamel-v1-nl-uiuc Files and directory structure required in $FG_ROOT/Aircraft/ to fly the model: sopwithCamel-v1-nl-uiuc-set.xml sopwithCamel/Models/uiuc/sopwithCamel/cambelg0.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg1.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg2.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg3.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg4.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg5.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg6.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg7.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg8.bmp sopwithCamel/Models/uiuc/sopwithCamel/cambelg9.bmp sopwithCamel/Models/uiuc/sopwithCamel/Sop-panel.bmp sopwithCamel/Models/uiuc/sopwithCamel/camel.txt sopwithCamel/Models/uiuc/sopwithCamel/cambelg.mdl sopwithCamel/Models/uiuc/sopwithCamel/sopwithCamel-model.xml sopwithCamel/Sounds/uiuc/sopwithCamel-sound.xml UIUC/sopwithCamel-v1-nl/aircraft.dat UIUC/sopwithCamel-v1-nl/CDfa-06.dat UIUC/sopwithCamel-v1-nl/CLfa-06.dat UIUC/sopwithCamel-v1-nl/Cmfa-06.dat UIUC/sopwithCamel-v1-nl/Cmfade-03.dat UIUC/sopwithCamel-v1-nl/README.sopwithCamel.html These files above come with the FlightGear base package. ~~ Model description and updates: 11/9/2002 - First release: v1-nl * Motivation: FGFS and the UIUC aero model were used to develop the flight model of 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.F. Scrub ([EMAIL PROTECTED]) has granted FlightGear permission to use and release the external model files with FlightGear under the GNU GPL. * 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 -180 to +180 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. * Interesting flight characteristics to note: - The Sopwith Camel was considered a beast to fly. It killed 385 pilots while they were in training (non-combat). In combat, 415 of the surviving pilots were killed while flying the Sopwith Camel. Approximately 5000 Sopwith Camels were built, and it is believed that collectively 1294 enemy aircraft were destroyed. - In large part, the challenges to flying the Sopwith Camel involve the large gyroscopic forces from the rotating engine. Pulling nose up causes the aircraft to yaw to the right, yaw right and it noses down, nose down and it yaws left, yaw left and it noses up. Thus whatever the direction the nose goes, the airplane slews to the right of that path. This was particularly dangerous for right-hand turns if not properly managed. The initial roll to the right takes place without any surprise. But after having banked, pulling up
Re: [Flightgear-devel] Wright Flyer progress
At 11/9/02, you wrote: Progress has been slow, mostly because of real work getting in the way, but the Wright Flyer is getting much closer to completion. Most of the detail and animation is done. Here's a shot from the front with the elevator mechanism tilted up for initial ascent.: http://www.spiderbark.com/fgfs/wrightflyer-starting.png From the earlier discussion and pictures available I took a guess on the wing warping. For now the animation is pretty crude (only three positions), but better than nothing. This is a shot from behind showing the wings warped for a roll toward the left: http://www.spiderbark.com/fgfs/wrightflyer-warp.png This is the startup line I'm using. The location and heading is based on a best guess from various accounts. Pictures of the Wright National Monument and a scan of a guide brochure from the Park helped a lot in at least matching reasonably close to the best guess that was arrived at in 1928 by a contingent of witnesses to the original event: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc --lat=36.020247 --lon=-75.669041 --heading=5 --disable-random-objects --enable-auto-coordination I have included the flag --enable-auto-coordination inside the -set.xml file and committed that to the cvs, so it's not needed on the command line anymore. Regards, Michael Crazy details left on my todo list: - Adding control cables/chains and blocks for all the control surfaces. - Animating Orville's hips and the cradle. - As soon as I figure out the exact shape, adding the foot stop that kept Orville from sliding off the back of the wing at startup. - As soon as I get some more information (a good picture or diagram), modeling the instrument cluster that was mounted just to the right of Orville's right arm. - Correct the elevator animation once information on its actual range is learned (anyone know this?) - Modeling the rail. - Modeling the rear skid (this is tricky because it gets dropped and left behind when the aircraft becomes airborn). I'm really not up to speed on scenery modeling, but if someone wants to it'd be great to have a tiny bit of territory covering just Kill Devil Hills, NC and the Outer Banks, that was simply covered with a nice beach sand texture as it was back in 1903. Another idea: if we had that little chunk of sandy scenery we might want to put together a special release (that included a binary and a tiny subset of the base package) for school teachers and whoever else to download during the centennial year. Might be kind of cool to release it next month on December 17th, the 99th aniversary of the first flight. Sounds like a potential promotional thing for the FlightGear project too, I'd think. Best, Jim ___ 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] Engine models: start-up and commonality betweenFDMs
Julian Foad wrote: David Megginson wrote: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. Well, for the record, I think this is a great idea. It really wouldn't be hard at all to wire up an interface between YASim's Thruster class and an external engine/propeller representation. What's that bit about the separate output mp? An engine doesn't produce zero thrust at idle, just a low thrust. And manifold pressure isn't supposed to be related to thrust in a simple way, is it? I should have written power instead of thrust, of course. The real point is that the output power of an ideal engine at peak mixture is proportional to the mass input, which is proportional to the product of RPM and manifold pressure. So an ideal engine will produce zero power only at zero MP. ...which is ridiculous, of course. In the real world, engines have a minimum MP when the throttle is at idle, and produce near-zero usable power at that MP. This is because of all kinds of complicated internal losses (pressure drop across the intake valves, internal friction, you name it...). I couldn't simply assume that an engine that produced 200 HP at 29 inches of MP would produce 41 HP (6/29 of 200) at idle; nor could I come up with a good/broad/general thermodynamic argument for what those losses should be. However, I had an empirical number from Dave Luff that engines idle at about 6 inches. So I cheated and interpolated from that point instead. :) When I'm running this at idle, _egt comes out at 80 (kelvin); presumably this should be added to ambient temp (which is 288) rather than clamped to it: That sounds like a bug. I'd have to look more carefully at the physics to be sure. But adding the temperature to ambient is almost guaranteed to be wrong. There are exactly zero adiabatic processes that are symmetric with change of temperature; that's what the second law of thermodynamics is all about. More likely, I'm converting the units incorrectly or using a miscalibrated value for power due to the hack above. 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. One issue is that the moment of inertia for the Cub looks too big. The current value is the same as the one for the 172, which has a larger prop. All other things being equal, it should scale with the mass of the propeller; I'd try a value about half of the Cessna's. This will result in too much stored energy in the prop that has to be dissipated, and thus a longer run-down (and run-up) time. You could also try increasing the 10% of cruise torque value that gets used for internal friction. I don't have any good numbers for what is appropriate, so I guessed. This is the kind of value that could/should be made tunable via configuration. I'd *love* to see good numbers for propeller acceleration, however. If one of the Real Pilots out there could go out with a stopwatch and get us graphs of RPM vs. time for full throttle acceleration and cut-power deceleration I'd be eternally grateful. :) 4. That negative torque: Interpolate it away as we approach cruise RPMs, though, to prevent interaction with the power computations. Ugly. Actually, the only way the variable power is used after that point is to compute the EGT, and that wants to know thermally developed power anyway (i.e. excluding the starter motor contribution and the friction reduction) so that should be fine. The engine power numbers are also used to handle the propeller solution too. My thinking here appears to have been that I didn't want an extra value interfering with the solver in funny ways. It's possible that all the changes cancel out later; just realize that the numbers get used outside the function, too. By the way, the experimental values here were with j3cub-yasim because c172-yasim gives a solution failure for elevator. Oh dear, is there another solver issue? This works fine for me. Are you absolutely sure you have current YASim code and base package? Platform/compiler? This is the solution result that I see: YASim solution results: Iterations: 362 Drag Coefficient: 18.0245 Lift Ratio: 90.6643 Cruise AoA: -0.131865 Tail Incidence: 0.582091 Approach Elevator: -0.920007 CG: -2.404, -0.033, 0.218 For all this, my original aim was just to get simple things like a realistic cranking speed of about 100 RPM, and some rotation sound while the engine is spinning down after being switched off! The sound issue is trivial -- just have one sound for the propeller noise that scales with RPM, and another for engine noise that is gated on /engines[0]/running. The realistic cranking speed is just a
