Re: [Flightgear-devel] Flight Gear for Simulation Visualization
Hi Chris, Flightgear will already visualize external data, I've done it, just not that often or recently and I can't remember the steps. Have a look at Docs/readme.IO and Docs/readme.protocol and look at the prewritten protocol files in Protocol/ Ron On Wednesday 17 April 2013 02:31:21 Christopher Fourie wrote: > Hi Everyone, > > My name is Chris Fourie - I'm a master's student in control engineering. My > work is in control systems for the autonomous flight of aircraft (primarily > helicopters). > > We do most of our simulations in MATLAB and a few other things, and I'm > looking for a good way to visualize the data that I generate in simulation. > I'm hoping to use flight gear - I have the source code but I'm struggling > to work out how everything fits together without detailed documentation. > > I'm looking to modify flightgear so that I'm able to set up a simulation > environment (using UDP for online simulation) as well as use it for offline > simulation (watching trajectories and motion using offline data that I've > generated). I need to set up environments with static landing points as > well as with moving platforms (eg. aircraft carriers) to ensure that the > systems we design work. > > I'm a bit at a loss as to where to start - I don't have that much > experience in graphics programming (not that I'm unwilling to learn though, > its really interesting) and I can't seem to find detailed information on > how everything in the code fits together. > > Is there any one that may have the time to help me or point me in the right > direction? > > Many thanks, > > Chris Fourie > ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies > and e-mail disclaimer published on our website at > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 > 21 650 9111. This e-mail is intended only for the person(s) to whom it is > addressed. If the e-mail has reached you in error, please notify the > author. If you are not the intended recipient of the e-mail you may not > use, disclose, copy, redirect or print the content. If this e-mail is not > related to the business of UCT it is sent by the sender in the sender's > individual capacity. ### -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Saturday 08 December 2012 12:12:23 Ron Jensen wrote: > I took a quick look through the FGData Aircraft directory today and came up > with a list of some 27 JSBSim piston engines that still seem to be using > either the old aeromatic default values for idle manifold pressure (minmp) > or suspiciously low values. > > As time permits this week I intend to take a deeper look at this list and > adjust the minmp value as seems appropriate, if there are no objections. > I know a couple of engines have different versions in other repositories > (JSBSim or personal hangers) that are updated and just need to be copied > into FGData. > > Ron Some of this work is done and was committed today, but there are still a dozen engines left to check, I will try to complete those as time permits. Thanks, Ron Done: Dragonfly/Engines/Rotax582.xml: 2.1 Raised to 7.5, Lowered map lag to 0.1, lowered static friction to 0.5. flight test good Aerocar/Engines/Lycoming_O-290.xml: 6.0 Raised to 10.1, flight test OK, propeller loads too much to reach 2800 RPM Boeing314/Engines/WrightGR-2600.xml:6.0 Raised to 10.0, flight test OK, propeller configuration questionable c150/Engines/eng_O-200.xml: 6.0 Copied my development engine over. Tweaked propeller and FDM for fair flight numbers. Needs more work. c172r/Engines/engIO360C.xml:6.5 Raised to 10.0, flight test SKIPPED c182/Engines/engIO540AB1A5.xml: 6.5 Raised to 10.0, flight test not so great, FDM needs work. c310/Engines/engIO470D.xml: 6.5 Raised to 9.3, flight test good c310u3a/Engines/engIO470D.xml: 6.5 Raised to 9.3, flight test good dc2/Engines/R-1820-R52.xml: 6.0 Raised to 9.8, flight test good flash2a/Engines/503.xml:2.0 Rewrote engine and propeller configurations. flight test good Won't fix: an2/Engine/ASH-62IR.xml:5.0 Seems O.K., can't get it to start, too much non-standard stuff in the system configuration G-164/Engines/R-1340-AN1.xml: 7.0 Dromader/Engine/engine_Asz-62IRM18.xml: 5.0 This stalls out at min throttle, but it may be intended by the author. Skyranger/Engines/rotax.xml:6.0 Primarily a YASim model, jsbsim just an aeromatic shell, won't touch. c182rg/Engines/engIO540AB1A5.xml: 6.5 Took my name off this, won't touch. Probably won't idle: dc6/Engines/CB17.xml: 6.0 dc6/Engines/eng_R-2800.xml: 6.5 fkdr1/Engines/Oberursel-UrII.xml: 6.0 Lockheed1049/Engines/WrightCyclone-975C18CB1.xml: 6.0 Lockheed1049h/Engines/WrightCyclone-972TC18DA3.xml: 6.0 Lockheed1049h/Engines/WrightCyclone-975C18CB1.xml:6.0 Noratlas/Engines/Bristol-739.xml: 6.0 ogel/Engines/200hp-jsbsim-2.0.xml: 6.0 P-38-Lightning/Engines/Allison.xml: 6.0 p51d/Engines/Packard-V-1650-7.xml: 4.0 PBY-Catalina/Engines/PBY-6_engine-new.xml: 6.0 Storch/Engines/Argus_As_10.xml: 6.0 Assumed Good: A6M2/Engines/Sakae-Type12.xml: 10.5 b29/Engines/eng_R3350.xml: 12.0 c172p/Engines/eng_io320.xml:8.3 C684/Engines/6Pfi.xml: Cap10B/Engine/LycomingIO360B2F.xml:12.0 Cessna337/Engines/engine_IO360C.xml: 15.0 ercoupe/Engines/c-75-12.xml: 10.0 Nordstern/Engines/eng_Maybach_Mb_IVa.xml: 9.0 SenecaII/Engines/tsio360eb.xml: 10.0 Short_Empire/Engines/eng_PegasusXc.xml: 10.0 Submarine_Scout/Engines/eng_RRhawk.xml: 10.0 ZivkoEdge/Engines/io540.xml:10.0 ZLT-NT/Engines/engIO360C.xml: 10.0 -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
On Sunday 13 January 2013 16:38:29 Jon S. Berndt wrote: > > Yes, i had hoped, too. However, as you mentioned, many new features > > have been developed and that violates our feature freeze rule, > > unfortunately. > > That rule has been introduced for exactly this situation: not to raise > > some last minute issues (to avoid "bugs" here). > > > > Sorry - but as we improve our plan with every release, this most likely > > will not happen again ;-) > > > > Torsten > > When was the last time that JSBSim was synched with FlightGear? > > Jon We synced about six months ago just before the last release of FGFS. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 13:49:51 Eric van den Berg wrote: > So it is kind of modelled like an air pump. Interesting method. Piston engines are basically air pumps. We currently calculate power by dividing the mass fuel flow by the user-entered bsfc multiply by correction factors for mixture and spark and subtract a little bit for good measure. The little bit ensures the engine stops spinning if it isn't producing power. The propeller code will keep it spinning under certain conditions, and needs to be fixed up to let it start the engine spinning again... If I were to start over with this model the biggest thing I would change would be replacing the power calculation with the Otto cycle[note 2] pressure calculations. We already (as mentioned) calculate the area of [1:2]+[6:1] as pumping losses.[note 3] The trick to this method is calculating the [3:4] pressure rise to get the area of [3:4:5:6] This should let us roll the egt and cylinder temp calculations into the power loop and make them more meaningful. Right now they are largely just indications, altough egt does indicate power somewhat correctly. That may be done in the future as we can then more easily add a diesel cycle. Ron [2] http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/otto.html#c5 [3] http://mae.wvu.edu/~smirnov/mae320/figs/F9-2.jpg > BTW > p0 =101325 Pa > R = 287.05 > Cp_air = 1004.68 > gamma = 1.4 > > Handbook of Aviation fuel properties, third edition: > net heat of combustion of AVGAS, all grades : min. 43.5 MJ/kg, 44 typical > density of AVGAS: 710 at 15degC > C_p_AVGAS = 2.065 kJ/kg K @20degC, approx linear to 2.710 @140degC > > hope this might improve accuracy (a bit), > > Cheers, > > Eric > > On 12/11/2012 07:35 PM, Ron Jensen wrote: > > On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: > >> I see. > >> Looking at the code (I think) I can see you are trying calculate the > >> pressure losses in the injector/throttle valve, "airbox" and inlet > >> tubes. Using throttle position and engine speed (was expecting cylinder > >> displacement here also). > > > > The displacement is somewhat irrelevant in that it is a constant and can > > be ignored. The modeler provides two data points; the pressure at full > > throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. > > These are used to determine the impedance of the airbox and throttle > > respectively. In this scheme, the engine is also treated as an impedance > > which varies with ( 1 / engine speed ) giving infinite impedance at 0 > > RPM[1] and falling towards, but never reaching, 0 impedance as engine > > speed increases. > > > > > > We experimented with many other and more complicated intake models early > > on, and this is the best behaved of the lot. > > > >> Basically your MAP at idle is to low, thus the > >> pressure loss too high. As 99% of the pressure loss comes from the > >> injector/throttle position, I would say for idle power setting the > >> injector air valve should be a bit more open? > >> > >> > >> > >> > >> I assume it is only calculated for indication and not for engine power > >> calcs? > > > > Actually, the manifold pressure is used in three ways in the power > > calculations. First, it affects the mass flow rate. We assume an > > adiabatic process so the loss in pressure is accompanied by a > > corresponding loss of density. Second, the volumetric efficiency is > > reduced by the intake pressure being less than the exhaust pressure > > further reducing the mass flow rate. Finally, the pressure difference > > between intake and exhaust creates a direct power loss as work is > > performed to pull and maintain the manifold pressure drop. > > > > Ron > > > > [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 13:49:51 Eric van den Berg wrote: > So it is kind of modelled like an air pump. Interesting method. Piston engines are basically air pumps. We currently calculate power by dividing the mass fuel flow by the user-entered bsfc multiply by correction factors for mixture and spark and subtract a little bit for good measure. The little bit ensures the engine stops spinning if it isn't producing power. The propeller code will keep it spinning under certain conditions, and needs to be fixed up to let it start the engine spinning again... If I were to start over with this model the biggest thing I would change would be replacing the power calculation with the Otto cycle[note 2] pressure calculations. We already (as mentioned) calculate the area of [1:2]+[6:1] as pumping losses.[note 3] The trick to this method is calculating the [3:4] pressure rise to get the area of [3:4:5:6] This should let us roll the egt and cylinder temp calculations into the power loop and make them more meaningful. Right now they are largely just indications, altough egt does indicate power somewhat correctly. That may be done in the future as we can then more easily add a diesel cycle. Ron [2] http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/otto.html#c5 [3] http://mae.wvu.edu/~smirnov/mae320/figs/F9-2.jpg > BTW > p0 =101325 Pa > R = 287.05 > Cp_air = 1004.68 > gamma = 1.4 > > Handbook of Aviation fuel properties, third edition: > net heat of combustion of AVGAS, all grades : min. 43.5 MJ/kg, 44 typical > density of AVGAS: 710 at 15degC > C_p_AVGAS = 2.065 kJ/kg K @20degC, approx linear to 2.710 @140degC > > hope this might improve accuracy (a bit), > > Cheers, > > Eric > > On 12/11/2012 07:35 PM, Ron Jensen wrote: > > On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: > >> I see. > >> Looking at the code (I think) I can see you are trying calculate the > >> pressure losses in the injector/throttle valve, "airbox" and inlet > >> tubes. Using throttle position and engine speed (was expecting cylinder > >> displacement here also). > > > > The displacement is somewhat irrelevant in that it is a constant and can > > be ignored. The modeler provides two data points; the pressure at full > > throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. > > These are used to determine the impedance of the airbox and throttle > > respectively. In this scheme, the engine is also treated as an impedance > > which varies with ( 1 / engine speed ) giving infinite impedance at 0 > > RPM[1] and falling towards, but never reaching, 0 impedance as engine > > speed increases. > > > > > > We experimented with many other and more complicated intake models early > > on, and this is the best behaved of the lot. > > > >> Basically your MAP at idle is to low, thus the > >> pressure loss too high. As 99% of the pressure loss comes from the > >> injector/throttle position, I would say for idle power setting the > >> injector air valve should be a bit more open? > >> > >> > >> > >> > >> I assume it is only calculated for indication and not for engine power > >> calcs? > > > > Actually, the manifold pressure is used in three ways in the power > > calculations. First, it affects the mass flow rate. We assume an > > adiabatic process so the loss in pressure is accompanied by a > > corresponding loss of density. Second, the volumetric efficiency is > > reduced by the intake pressure being less than the exhaust pressure > > further reducing the mass flow rate. Finally, the pressure difference > > between intake and exhaust creates a direct power loss as work is > > performed to pull and maintain the manifold pressure drop. > > > > Ron > > > > [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: > I see. > Looking at the code (I think) I can see you are trying calculate the > pressure losses in the injector/throttle valve, "airbox" and inlet tubes. > Using throttle position and engine speed (was expecting cylinder > displacement here also). The displacement is somewhat irrelevant in that it is a constant and can be ignored. The modeler provides two data points; the pressure at full throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. These are used to determine the impedance of the airbox and throttle respectively. In this scheme, the engine is also treated as an impedance which varies with ( 1 / engine speed ) giving infinite impedance at 0 RPM[1] and falling towards, but never reaching, 0 impedance as engine speed increases. We experimented with many other and more complicated intake models early on, and this is the best behaved of the lot. > Basically your MAP at idle is to low, thus the > pressure loss too high. As 99% of the pressure loss comes from the > injector/throttle position, I would say for idle power setting the injector > air valve should be a bit more open? > I assume it is only calculated for indication and not for engine power > calcs? Actually, the manifold pressure is used in three ways in the power calculations. First, it affects the mass flow rate. We assume an adiabatic process so the loss in pressure is accompanied by a corresponding loss of density. Second, the volumetric efficiency is reduced by the intake pressure being less than the exhaust pressure further reducing the mass flow rate. Finally, the pressure difference between intake and exhaust creates a direct power loss as work is performed to pull and maintain the manifold pressure drop. Ron [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 00:55:35 Eric van den Berg wrote: > Ron, > > From experience: the lyco IO540 idles at 14-15 inHG, 900RPM (MT-prop with > P-880-xx governor) > > Eric > Thanks Eric, The JSBSim piston engine model is missing something, probably Mach effect through the intake valve, so models tend to idle at lower manifold pressures than real engines. The current code idles most engines around 10-11 inHg, but the oldest code used 6 inHg... Ron -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim Piston Engine Idle
I took a quick look through the FGData Aircraft directory today and came up with a list of some 27 JSBSim piston engines that still seem to be using either the old aeromatic default values for idle manifold pressure (minmp) or suspiciously low values. As time permits this week I intend to take a deeper look at this list and adjust the minmp value as seems appropriate, if there are no objections. I know a couple of engines have different versions in other repositories (JSBSim or personal hangers) that are updated and just need to be copied into FGData. Ron Probably won't idle: Aerocar/Engines/Lycoming_O-290.xml: 6.0 an2/Engine/ASH-62IR.xml:5.0 Boeing314/Engines/WrightGR-2600.xml:6.0 c150/Engines/eng_O-200.xml: 6.0 c172r/Engines/engIO360C.xml:6.5 c182/Engines/engIO540AB1A5.xml: 6.5 c182rg/Engines/engIO540AB1A5.xml: 6.5 c310/Engines/engIO470D.xml: 6.5 c310u3a/Engines/engIO470D.xml: 6.5 dc2/Engines/R-1820-R52.xml: 6.0 dc6/Engines/CB17.xml: 6.0 dc6/Engines/eng_R-2800.xml: 6.5 Dragonfly/Engines/Rotax582.xml: 2.1 Dromader/Engine/engine_Asz-62IRM18.xml: 5.0 fkdr1/Engines/Oberursel-UrII.xml: 6.0 flash2a/Engines/503.xml:2.0 Lockheed1049/Engines/WrightCyclone-975C18CB1.xml: 6.0 Lockheed1049h/Engines/WrightCyclone-972TC18DA3.xml: 6.0 Lockheed1049h/Engines/WrightCyclone-975C18CB1.xml:6.0 Noratlas/Engines/Bristol-739.xml: 6.0 ogel/Engines/200hp-jsbsim-2.0.xml: 6.0 P-38-Lightning/Engines/Allison.xml: 6.0 p51d/Engines/Packard-V-1650-7.xml: 4.0 PBY-Catalina/Engines/PBY-6_engine-new.xml: 6.0 Skyranger/Engines/rotax.xml:6.0 Storch/Engines/Argus_As_10.xml: 6.0 Maybe: G-164/Engines/R-1340-AN1.xml: 7.0 Good: A6M2/Engines/Sakae-Type12.xml: 10.5 b29/Engines/eng_R3350.xml: 12.0 c172p/Engines/eng_io320.xml:8.3 C684/Engines/6Pfi.xml: Cap10B/Engine/LycomingIO360B2F.xml:12.0 Cessna337/Engines/engine_IO360C.xml: 15.0 ercoupe/Engines/c-75-12.xml: 10.0 Nordstern/Engines/eng_Maybach_Mb_IVa.xml: 9.0 SenecaII/Engines/tsio360eb.xml:10.0 Short_Empire/Engines/eng_PegasusXc.xml:10.0 Submarine_Scout/Engines/eng_RRhawk.xml:10.0 ZivkoEdge/Engines/io540.xml: 10.0 ZLT-NT/Engines/engIO360C.xml: 10.0 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim models
On Sunday 28 October 2012 23:01:04 kunai...@yahoo.co.jp wrote: > Hi - I'm kunai. I have some questions about Aeromatic > that hopefully some of you > can give me answers. > 1) Is it possible to use Aeromatic to make a helicopter model ? There is no 'aeromatic' support for JSBSim helicopters at this time. > 2) Which engine type should be chosen at step3 (of Aerimatic) when making > a helicopter model? The JSBSim rotor model supports electric, piston and turboprop engine types. Aeromatic will generate a decent piston engine, the other two you need to start from an example. There is also one or two example helicopters in JSBSim stand-alone to get you started. Ron -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Physics engine of Flightgear
On Friday 19 October 2012 04:37:50 kunai...@yahoo.co.jp wrote: > Thank you Jon for your reply. > I am still a bit confused. Which one of the two is correct ? > > 1) YAsim or JSBsim is used to specify only aircraft flight model > parameters and the > physics flight dynamics engine is a separate component that uses these > parameters. In this case, > what physics-based Flight Dynamics Engine (FDE) is used ? > > 2) YAsim/JSBsim is to be considered an integrated systems that utilizes > aircraft flight > model parameters given by the user in conjunction with an internal FDE. > > My interest is in the physics-based FDE. If there is information about > the FDE used in FlightGear, > please give me some references. Neither. YASim and JSBSim are separate choices for the physics of flight modeling. There is no underlying "FDE" as you put it. http://wiki.flightgear.org/JSBSim http://wiki.flightgear.org/YASim Ron -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On Monday 08 October 2012 02:20:25 James Turner wrote: > On 8 Oct 2012, at 07:47, ThorstenB wrote: > > On 7 Oct 2012, at 15:19, Stuart Buchanan wrote: > >> The use-case is to enable or disable particular views if you don't want > >> to have to spend ages cycling through them. > > > > I also quite like this option. Some a/c also provide many additional > > custom views. It's handy to just enable the personal favourites. > > Okay - I guess since my yoke has a button bound to 'cycle views' I've got > used to rapidly clicking through. I have a button bound, but still frequently turn off a few views... > > Personal taste: I'd keep the views named as "views" and just merge the > > dialogs. > > Yep, definitely gets my vote. One issue might be, since aircraft can define > custom views, making the dialog a sensible proportion. But I don't believe > many aircraft define more than an extra 4-5? I'm against merging views and rendering dialogs. They perform two distinctly different functions. Views simply select which views are cycled through and rendering options gets into much detailed and global changes to the way the flightgear world looks. Please don't overload grandpa! Thanks, Ron -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logitech force 3d pro hat question?
On Saturday 22 September 2012 14:04:10 Matevž Jekovec wrote: > Hi guys. > > I'm using Logitech force 3d joystick (force-3d-pro.xml) and the Y hat is > inversed. When I do hat up, it actually looks down and vice versa. Is > this the expected behaviour? Its personal preference, I think. I like the hat to follow the stick. Pushing forward looks down and pulling back looks up. I know this is reversed from some/many first-person shooter games, but as a long-time sim pilot it is much more intuitive for me this way. > I then changed two values from positive to negative of the view > elevation in the config and it works fine now. I attached the patch. > What do you think? I use all custom bindings anyway. :) Ron -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] license
On Wednesday 05 September 2012 05:04:06 Martin Spott wrote: > Scott wrote: > > But more seriously, I'm no license guru, and you picked one of the main > > points I'm not clear on, the original CC in this example is > > "Share-alike" and "Derived works allowed with attribution". > > It really depends on the particular phrasing in license text. > One of the - various - reasons for not providing 'official' FlightGear > Scenery with OSM roads is the clause in CC-BY-SA 2.0, which says: > > "If you alter, transform, or build upon this work, you may distribute > the resulting work only under the same or similar license to this > one." > > > whereas the GPL is widely considered as not being sufficiently > "similar", despite the fact that the *intention* isn't that much > different. > > Cheers, > Martin. IANAL. The issues are non-commercial and attribution. The attribution clause is effectively the BSD advertising clause, which is a horrible idea on multiple levels. http://www.gnu.org/philosophy/bsd.html And has been pointed out, selling of flightgear does have a legitimate place. Ron -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Starting engine using FGNetCtrls
There is a change to the starter motor code (should be entering git real soon now) that may help address this. But your engine should have 'started' as it exceeded 440 RPM... Anyway, glad it works now, and we can revisit this after FlightGear syncs JSBSim. Ron On Friday 01 June 2012 09:39:52 Viktor Radnai wrote: > Hi Ron, > > A quick test confirms that you were indeed right: > > Engine state: 0, mag: 3, starter: 1, RPM: 440.915466 > Engine state: 0, mag: 3, starter: 1, RPM: 440.567566 > Engine state: 0, mag: 3, starter: 1, RPM: 447.837677 > Engine state: 0, mag: 3, starter: 1, RPM: 445.897156 > > > It must be that the periodic engaging and disengaging of the starter > makes it impossible to reach 550 rpm. If I also press 's' in Flightgear, > the engine will start immediately. Also if I reset the game and the prop > is still turning, it will start. > > I do find it a bit odd how the starter was implemented. I wonder if it's > feasible to change it so it keeps running until a starter_power=0 is > received. In the meantime I might just change the idle RPM to 440 in my > copy so I'm able to start the engine. > > Thanks for your help! > > Cheers, > Vik > > On 06/01/2012 02:16 AM, Ron Jensen wrote: > >> From eng_io320.xml: > > > > 550.0 > > > > The engine needs to reach 440 RPM to start (80% of 550, the coded idle > > RPM) if you're reaching above 440 RPM make sure you've engaged fuel and > > magneto controls. If you're not reaching that perhaps you need to look > > into the controlling nasal as the c172 uses some non-standard stuff. Also > > make sure you're not sitting with a strong tailwind as that can affect > > some propeller configurations and make them harder to turn. > > > > Ron > > > > On Thursday 31 May 2012 15:16:42 Viktor Radnai wrote: > >> Hi all, > >> > >> I'm going to use Flightgear for developing/testing UAV code (yep, > >> another one of those :) ). I'm currently putting together an SDL app > >> that communicates with FG. > >> > >> I'm using the FGNetCtrls structure from net_ctrls.hxx. I'm trying to > >> start the C172's engine but when I set startup_power = 1, the engine > >> tries to start, but won't. Flightgear behaves like I was repeatedly > >> pressing the 's' key several times per second rather than holding it > >> down, so the engine spins up, but not quite enough to start. Am I doing > >> something wrong? > >> > >> Thanks for your help in advance. > >> > >> Cheers, > >> Vik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Starting engine using FGNetCtrls
>From eng_io320.xml: 550.0 The engine needs to reach 440 RPM to start (80% of 550, the coded idle RPM) if you're reaching above 440 RPM make sure you've engaged fuel and magneto controls. If you're not reaching that perhaps you need to look into the controlling nasal as the c172 uses some non-standard stuff. Also make sure you're not sitting with a strong tailwind as that can affect some propeller configurations and make them harder to turn. Ron On Thursday 31 May 2012 15:16:42 Viktor Radnai wrote: > Hi all, > > I'm going to use Flightgear for developing/testing UAV code (yep, > another one of those :) ). I'm currently putting together an SDL app > that communicates with FG. > > I'm using the FGNetCtrls structure from net_ctrls.hxx. I'm trying to > start the C172's engine but when I set startup_power = 1, the engine > tries to start, but won't. Flightgear behaves like I was repeatedly > pressing the 's' key several times per second rather than holding it > down, so the engine spins up, but not quite enough to start. Am I doing > something wrong? > > Thanks for your help in advance. > > Cheers, > Vik > > --- >--- Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Please sync JSBSim before the freeze? Attn: Erik!
Would it be possible to sync JSBSim and flightgear? There are a couple of changes to JSBSim I'd like to get into the next flightgear: New tags for the piston engine model: Allows a power penalty for boosting manifold pressure. This can be adjusted at run-time by changing the boostloss-factor property Associated properties: propulsion/engine[*]/boostloss-factor propulsion/engine[*]/boostloss-hp (read only) This tag will allow the engine's manifold pressure to change faster (or slower) than it currently does. These two tags control the starter motor. Starter-torque is the 0 RPM twisting force and starter-rpm is where the RPM where the starter motor ceases to produce power. Associated properties: propulsion/engine[*]/starter-norm This property can be set to 0 to disable the starter motor, or set to a value to simulate a low battery or a booster cart. Finally, I exposed an extra property: propulsion/engine[*]/friction-hp This can be set to a high value to 'seize' an piston engine. Thanks, Ron -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Total aero Moment != Total Moment from all Cm ???
On Thursday 24 May 2012 01:26:35 Burin Sungketkit wrote: > I've checked the Total Aero Moment from /fdm/jsbsim/moments/m-aero-lbsft > and compared with the summation of all Cm from aerodynamics section. > > Do these two properties have to be equal or not? (I think it should be > equal). > > This happended with FG V.2.0.0 and 2.4.0 but never test with FGv.2.6.0 and > with all aircraft. > > Please help me about this. They are equal only if, and only if, the center of gravity (CG) is equal to the aerodynamic reference (aerorp) point. Otherwise, when AeroRP != CG you get sum(aero/moments) + sum(aero forces)*(AeroRP-CG). In other words, the aerodynamic forces set up moments as well. Those are visible in the main property "moments/m-aero-lbsft" but aren't created by the moment axises in the FDM file so they don't appear in your Cm properties. Ron -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
On Friday 18 May 2012 10:59:22 Alan Teeder wrote: > On the subject of frames rates I have a couple of questions. > 2. Is there a mechanism for making the core - fdm, afcs, equations of > motion etc. run at a higher priority than the rest of the simulation? The JSBSim FDM and systems coded in JSBSim run at or near a stable 120Hz by running multiple times per graphics frame. Ron -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] List Etiquette was airport list
On Thursday 12 April 2012 16:11:14 gap...@gapalp.net wrote:
> Wow, this works better, is simpler code, and is much
> faster! Plus it will be easy to allow the user to pass configurations such
> as range and airport type as mentioned, to suit GA planes or
> heavies. AirportInfoFilter
> filter; double maxRange =
> 300.0; FGPositioned::List results =
> FGPositioned::findWithinRange(globals->get_aircraft_position(), range,
> &filter); FGPositioned::sortByRange(results,
> globals->get_aircraft_position()); string
> dest[results.size()]; for (unsigned int i=0; i <
> results.size(); i++) {
> dest[i] = results[i]->ident();
> }gapalp href="mailto:gap...@gapalp.net";>gap...@gapalp.netiv>
Please send your mails to this list in plain text not HTML.
Thank you,
Ron
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On Monday 09 April 2012 15:05:58 Torsten Dreyer wrote: > Hi, > > what is our current policy for updates to nav.dat? Do we commit changes > to the binary gzip'ed file or do we have a central repository for the data? > > Would it make sense to have the unzip'ed file in git and zip it for the > release in "make dist"? > > Torsten I think it would be a great idea to gunzip nav.dat and apt.dat in git. Ron -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
On Tuesday 03 April 2012 18:38:55 syd adams wrote: > > I assume that users complaining about ugly models is the only means to > > make many of the modellers fix their stuff. > > > > Cheers, > > Martin. > > True :). Although it would be a great help to know what needs changing > ... apparently I've missed an email. > At the moment rembrandt is unusable for me , 5 fps , but i do like the > aircraft self-shadowing. > Great work ! > Syd AnderG suggested to me adding these two to my command line. --prop:/sim/rendering/random-vegetation=0 --prop:/sim/rendering/shaders/quality-level=0 Those bring my 8500 GT and single core semperon system up to 15 fps. Ron -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
On Monday 19 March 2012 07:22:52 Renk Thorsten wrote: > > You ought to be able to initialize any vehicle at any altitude (up to and > > even beyond 3000 km). At this time, only the Vostok has control jets, as > > far as I know. > > Actually I can not do that. Trying to initialize the ufo at 1.000.000 ft > works fine, and so does flying the ufo to the altitude. I've then removed > the altitude limit detection from the Vostok model leading to an automatic > scenario termination. Trying to initialize Vostok at 1.000.000 ft causes > Flightgear not to load properly (it gets stuck and some JSBSim messages > never appear), trying to fly up beyond 150 km altitude causes a crash of FG > shortly after reaching the red zone. So something is happening with a > JSBSim model which isn't happening with the ufo FDM. > > Cheers, > > * Thorsten I assume you ran into a bunch of PT_vs_hpt: ran out of layers for h= messages. This is from FlightGear's rather brittle atmosphere model. The attached patch adds a deep-space layer out to 1e9 meters. I just arbitrarily set the pressure to near 0 and the temperature to damn cold. This patch let me initialize a random JSBSim model at a million feet, however there were still some NaNs present in the property tree when I made it back to sea-level. Ron I sent this half an hour ago, and sourceforge ate it. I'll send it again to see if this one comes through in a timely fashion... diff --git a/src/Environment/atmosphere.cxx b/src/Environment/atmosphere.cxx index 022ea54..f16005f 100644 --- a/src/Environment/atmosphere.cxx +++ b/src/Environment/atmosphere.cxx @@ -18,7 +18,8 @@ ISA_layer(3, 32000, 104986, 868.019,0.256326, 228.65, -44.50, -0.0028, - ISA_layer(4, 47000, 154199, 110.906, 0.0327506, 270.65, -2.50, 0, 0), ISA_layer(5, 51000, 167322, 66.9389, 0.0197670, 270.65, -2.50, 0.0028, 0.0008534), ISA_layer(6, 71000, 232939, 3.95642, 0.00116833, 214.65, -58.50, 0.0020, 0.0006096), -ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50), +ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50, 0.0, 0.0), +ISA_layer(8, 1.0e9, 3.28e9, 0.1, 3.0e-9,2.73, -270.4, 0.0, 0.0), }; const int ISA_def_size(sizeof(ISA_def) / sizeof(ISA_layer)); -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
On Monday 19 March 2012 07:22:52 Renk Thorsten wrote: > > You ought to be able to initialize any vehicle at any altitude (up to and > > even beyond 3000 km). At this time, only the Vostok has control jets, as > > far as I know. > > Actually I can not do that. Trying to initialize the ufo at 1.000.000 ft > works fine, and so does flying the ufo to the altitude. I've then removed > the altitude limit detection from the Vostok model leading to an automatic > scenario termination. Trying to initialize Vostok at 1.000.000 ft causes > Flightgear not to load properly (it gets stuck and some JSBSim messages > never appear), trying to fly up beyond 150 km altitude causes a crash of FG > shortly after reaching the red zone. So something is happening with a > JSBSim model which isn't happening with the ufo FDM. > > Cheers, > > * Thorsten I assume you ran into a bunch of PT_vs_hpt: ran out of layers for h= messages. This is from FlightGear's rather brittle atmosphere model. The attached patch adds a deep-space layer out to 1e9 meters. I just arbitrarily set the pressure to near 0 and the temperature to damn cold. This patch let me initialize a random JSBSim model at a million feet, however there were still some NaNs present in the property tree when I made it back to sea-level. Ron diff --git a/src/Environment/atmosphere.cxx b/src/Environment/atmosphere.cxx index 022ea54..f16005f 100644 --- a/src/Environment/atmosphere.cxx +++ b/src/Environment/atmosphere.cxx @@ -18,7 +18,8 @@ ISA_layer(3, 32000, 104986, 868.019,0.256326, 228.65, -44.50, -0.0028, - ISA_layer(4, 47000, 154199, 110.906, 0.0327506, 270.65, -2.50, 0, 0), ISA_layer(5, 51000, 167322, 66.9389, 0.0197670, 270.65, -2.50, 0.0028, 0.0008534), ISA_layer(6, 71000, 232939, 3.95642, 0.00116833, 214.65, -58.50, 0.0020, 0.0006096), -ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50), +ISA_layer(7, 8, 262467, 0.88628, 0.000261718, 196.65, -76.50, 0.0, 0.0), +ISA_layer(8, 1.0e9, 3.28e9, 0.1, 3.0e-9,2.73, -270.4, 0.0, 0.0), }; const int ISA_def_size(sizeof(ISA_def) / sizeof(ISA_layer)); -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ercoupe (was auto-coordination)
On Friday 09 March 2012 14:45:45 Adam Dershowitz, Ph.D., P.E. wrote: > Few, but at least one: > > http://en.wikipedia.org/wiki/ERCO_Ercoupe > > > --Adam As the FDM maintainer for the Flightgear version of this airplane I have searched the interwebs for details on its rudder system and came up with nothing. Right now its implemented as a simple linear ratio of aileron to rudder. Is that how they're really built? Thanks, Ron -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a small set of minor aircraft model question...
On Tuesday 06 March 2012 03:33:55 Francesco Angelo Brisa wrote: > Thanks for the answers; > > based on you suggestions I think I will add instruments in the C337 way > (With a little thin glass in front of them with almost no reflection > effect). > > Cheers > Francesco I thought the overwhelming response was no glass reflections... Thanks, Ron -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a small set of minor aircraft model question...
On Monday 05 March 2012 02:53:59 Francesco Angelo Brisa wrote: > Hi > > I was going to take some time to put my hands on some aircraft, before > beginning I have some little questions: > > Aerostar 700: > * The airspeed indicator looks like to be a default one (With no colored > bars for velocities). is this due to the fact that it is as in the real > aircraft or just because nobody worked on it ? > > Generic questions... > * asi-300: > how was the asi-300.rgb (under Aircraft/Instruments-3d/asi300 folder) made > ? is it from some sort of svg ? if yes, where can I find it ? Not the same one, but: http://www.jentronics.com/fgfs/temp/asi001.ps http://www.jentronics.com/fgfs/temp/asi001.xcf the postscript file can be edited for different scales... > * Analogic instruments: > I was looking at two amazing done aircrafts: the DR400 and the Cessna 337; > the DR400 has instruments with a glass reflection (Which is very nice and > realistic) the C337 does not have it. I personally slightly prefer the C337 > way, a little more clean, but it is just my feeling. the question: what > would you suggest to do, if I want to take an aircraft, add a instrument, > which type should I use ? i.e. if I want to add instruments to the C310. Personally, I hate the glass shaders covering instruments and windows. I want to actually fly these aircraft and not drool over how 'real' they look. Flying means I need to be able to actually read the instrument, so I often prefer larger fonts and bolder lines than perhaps the original had. > http://i41.tinypic.com/10huog1.jpg > > [image: Immagine in linea 1] > > http://wiki.flightgear.org/images/f/fd/Cessna337-avionics.png > [image: Immagine in linea 2] > > * I was looking on internet to some cockpit image of some FG aircraft. what > I have found is a lot of different custom instruments set of the same > aircraft model. If I want to take an empty cockpit aircraft and I want to > add instruments to it, can I just choose a "cockpit model" and use it as > reference ? or is some kind of basic instruments set for any aircraft type > ? I hope I explained myself well... The original idea to have a basic set of instruments in Instruments-3d hasn't always worked out so well because underlying concepts of how things should work varied from designer to designer. Its my opinion things bit-rot slower if the instrument lives in its own aircraft. Thanks, Ron -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding an R/C pilot view
On Saturday 03 March 2012 21:14:45 Ian Dall wrote: > On Fri, 2012-03-02 at 12:39 -0600, Curtis Olson wrote: > > Hi Ian, > > > > If you wish to set your own tower position, it's pretty straight > > forward and can be done manually or via nasal or probably a few other > > mechanisms. > > > > > > By default flightgear will set the tower position to the nearest > > airfield, so to disable that, set: /sim/tower/auto-position = 0 > > > > > > Then you can set /sim/tower/longitude-deg, /sim/tower/latitude-deg, > > and /sim/tower/altitude-ft > > Ah, my "significant effort" comment was more to do with making an R/C > Flying Field as an "airport" than with tweaking the tower position. Also > people might not want the list of recognised airports cluttered up with > fake airports. > > What I am trying to a achieve is an interface a kid can operate with no > more difficulty than selecting a view (and preferably automatic). > Manually figuring out what latitude and longitude will give an offset of > a few meters in the right direction is definitely in the too hard > basket. I think Curt was trying to point out a way you could make something work from nasal without getting into core code. > The locate tower with a mouse click suggested by Gijs is closer > to the mark (though the link to the script doesn't work for me). Anyway, > the point is not so much how to implement the right view, as how the > user should invoke it. A "view" with the right characteristics seems to > be the best solution. An alternative, which you seem to suggest, would > be to customise the existing "Tower View". ... > > For RC views, you may also wish to play around with auto-zooming -- > > either to help keep the aircraft large enough to see, or help keep the > > horizon in view -- either can be useful at times with RC flying. > > Good point. I had though of (but not implemented) the "keep the aircraft > large enough" aspect but not the "keep horizon in view" one. Actually I > have just found your forum comment on this exact issue: > http://www.flightgear.org/forums/viewtopic.php?f=49&p=151251 > > I assume one would implement auto-zooming by adding nasal "update" > methods in view.nas. There is no existing support? Have you looked at the Fly-by view? It pans, rotates and moves itself to follow the aircraft already. It might be exactly what you're looking for if you were to adjust it so the moves weren't so random, its a bit disorienting when it jumps from side to side and above and below the model. If it always stayed at ground level and to the same side of the aircraft when moving it might make a nice automatic R/C view. Ron -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Windturbines facing in wrong wind
On Monday 27 February 2012 13:15:39 Martin Spott wrote: > Martin Spott wrote: > > I don't have an idea, why - maybe that's been the default in PPE, AC3D > > or whichever tool. Jon made me aware of this issue many years ago > > (when we started filling the scenery objects database) and, as far as I > > remeber, I found evidence that Jon is right. > > BTW, from my perspective AC3D orientation in FlightGear is another > issue worth fixing, but I'm uncertain wether it's clever to do both at > the same time. There might be reasons to leave the AC3D oriantation > the way it is, reasons which I'm completely unaware of. > > Cheers, > Martin. Please don't randomly change things. The model orientation, +X aft, +Z left and +Y up is a very common aerodynamic orientation. Ron -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git question
On Sunday 19 February 2012 15:28:05 Scott wrote: > On Sun, 2012-02-19 at 14:40 -0700, dave perry wrote: > > On 02/19/2012 02:06 PM, Torsten Dreyer wrote: > > > Am 19.02.2012 21:54, schrieb dave perry: > > >> Hi All, > > >> > > >> I have been gone for almost a year. I want to start new source trees > > >> for simgear and flightgear and track on going development. Which git > > >> branches should I "check out" in this new set of directories? And > > >> from the e-mails I have read from the developers list, is appears that > > >> fgdata still has all the aircraft under development. > > >> > > >> I plan to rate all the AC I have made significant contributions to via > > >> the published rules and push them to the repository. > > > > > > Hi Dave, > > > > > > welcome back! The latest development is in 'next' for SimGear and > > > FlightGear and 'master' for fgdata. Yes, fgdata still holds all > > > aircraft. > > > > > > Some basic instructions are in the wiki: > > > http://wiki.flightgear.org/Git > > > > > > Torsten > > > > > > --- > > >--- Virtualization& Cloud Management Using Capacity Planning > > > Cloud computing makes use of virtualization - but cloud computing > > > also focuses on allowing computing to be delivered as a service. > > > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > > ___ > > > Flightgear-devel mailing list > > > Flightgear-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > Thanks Torsten, > > > > The wiki link is just what I needed to refresh my memory. I their a > > similar reference for the change to cmake? > > > > Dave P. > > There is a README.cmake in the top level directory once you clone the > repository that is quite helpful. There is also the wiki page at > http://wiki.flightgear.org/Building_using_CMake > > Typing cmake and hitting the search button will find that for you from > the wiki front page :) > > > S. http://wiki.flightgear.org/Talk:Building_using_CMake I put some notes on the discussion page for that page, too... Ron -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH 8/9] remove unused percent_RPM local from FGPiston::doEnginePower
On Thursday 16 February 2012 02:07:53 Chris Forbes wrote:
> ---
> src/FDM/JSBSim/models/propulsion/FGPiston.cpp |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
> b/src/FDM/JSBSim/models/propulsion/FGPiston.cpp index 0f47018..dbd494c
> 100644
> --- a/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
> +++ b/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
> @@ -733,10 +733,9 @@ void FGPiston::doEnginePower(void)
>FMEP = 0;
>if (Running) {
> // FIXME: this needs to be generalized
> -double ME, percent_RPM, power; // Convienience term for use in the
> calculations +double ME, power; // Convienience term for use in the
> calculations ME =
> Mixture_Efficiency_Correlation->GetValue(m_dot_fuel/m_dot_air);
>
> -percent_RPM = RPM/MaxRPM;
> // Guestimate engine friction losses from Figure 4.4 of "Engines: An
> Introduction", John Lumley FMEP = (-FMEPDynamic * MeanPistonSpeed_fps *
> fttom - FMEPStatic);
I will apply this one upstream and let it trickle back down, thanks.
Ron
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final 2.6.0 Release Preparations
On Friday 10 February 2012 04:08:32 Torsten Dreyer wrote: > Hi all, > > for our release of version 2.6.0 next week, we have a few open items on > our checklist and I am kindly asking for support to get them done: > > 1. How are our release candidates performing? Are there any release > blocking bugs that should be taken care of? I found and fixed a potential NaN and Segfault in the JSBSim propeller code yesterday. It could be considered a blocking bug for 2.6 to me. The property /fdm/jsbsim/propulsion/engine/prop-induced-velocity_fps gives wrong answers, and can become NaN under certain conditions. When thrust is negative and forward velocity is small we can take the square root of a negative number. This could occur, for example, when using reverse thrusters on landing. The value comes out much too high when alpha is near 180, such as taxing with a tail wind. Thanks, Ron http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/models/propulsion/FGPropeller.cpp?r1=1.42&r2=1.43&view=patch --- FGPropeller.cpp 2011/12/22 22:13:59 1.42 +++ FGPropeller.cpp 2012/02/11 15:14:27 1.43 @@ -228,8 +228,16 @@ // Induced velocity in the propeller disk area. This formula is obtained // from momentum theory - see B. W. McCormick, "Aerodynamics, Aeronautics, // and Flight Mechanics" 1st edition, eqn. 6.15 (propeller analysis chapter). - Vinduced = 0.5 * (-Vel + sqrt(Vel*Vel + 2.0*Thrust/(rho*Area))); - + // Vinduced = 0.5 * (-Vel + sqrt(Vel*Vel + 2.0*Thrust/(rho*Area))) + // Since Thrust and Vel can both be negative we need to adjust this formula + // To handle sign (direction) separately from magnitude. + double Vel2sum = Vel*abs(Vel) + 2.0*Thrust/(rho*Area); + + if( Vel2sum > 0.0) +Vinduced = 0.5 * (-Vel + sqrt(Vel2sum)); + else +Vinduced = 0.5 * (-Vel - sqrt(-Vel2sum)); + // P-factor is simulated by a shift of the acting location of the thrust. // The shift is a multiple of the angle between the propeller shaft axis // and the relative wind that goes through the propeller disk. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wiki Spam
http://wiki.flightgear.org/Special:RecentChanges Someone is spamming our wiki. Anyone around with admin rights? Thanks, Ron -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p cockpit improvement
On Wednesday 21 December 2011 04:09:35 Stuart Buchanan wrote: > On Wed, Dec 21, 2011 at 11:00 AM, Torsten Dreyer wrote: > >> I prefer manually syncing and checking that the changes are valid, > >> rather than blindly over-riding what we've already got. > > > > Hi Stuart, > > > > this > > - > > - aero/alpha-rad > > - > > + aero/alpha-rad > > -1.8000 > > > > reintroduces a bug, IIRC that had something to do with tailwind > > behavior. I think we should keep the function. > > Agreed - that's a mistake in my checkin. I will correct it. > > -Stuart I missed backporting this to the JSBSim side. I've also got an experimental FDM with many more of these wrapped in sine or cosine functions as appropriate. This will make the forces and moments trend in the correct directions, even if the magnitudes aren't quite right. Perhaps a improved stall system for JSBSim will be ready for 2.8 Ron -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p cockpit improvement
On Wednesday 21 December 2011 14:50:39 Stuart Buchanan wrote: > On Wed, Dec 21, 2011 at 5:53 PM, Torsten Dreyer wrote: > >> Agreed - that's a mistake in my checkin. I will correct it. > >> > >> -Stuart > > > > OK - one more. > > > > velocity including the propulsion induced > > velocity. > > > > velocities/u-aero-fps > > propulsion/engine/prop-induced-velocity_fps > > propulsion/engine/prop-induced-velocity_fps > > > > > > > > Why is prop-induced-velocity_fps added twice? Is that by intention? > > > >From discussion with AndersG on IRC who checked his aerodynamics text, > > we believe it is intentional. > > "the final increase in slipstream velocity (over the free stream velocity) > is 2* the increase in velocity at the actuator disk. Which is consistent > with the c172p FDM " > > -Stuart Yes, its added twice to avoid the multiplication. Ron -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p FDM
Adding another adult in the front seat, and two large kids/small ladies in the back seat, as well as 50 lbs of luggage and a near full load of fuel: Mass Properties Report (English units: lbf, in, slug-ft^2) WeightCG-XCG-YCG-Z Base Vehicle 1500.041.0 0.036.5 0 Pilot 180.036.0 -14.024.0 1 Co-Pilot 180.036.014.024.0 2 Left Passenger 100.070.0 -14.024.0 3 Right Passenger100.070.014.024.0 4 Baggage 50.095.0 0.024.0 0 Fuel 170 56-11259.4 1 Fuel 170 56 11259.4 Total:2450.045.8 0.036.6 Using a script I wrote to simulate a softfield takeoff technique[1], I see the following: Using FlightGear's IO-320 and Propeller Flaps 0% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 14 41 2300 0 Rotation 25 64 2500 0 Lift off 32 74 2570 8 42 84 262562 324 fpm Distance traveled: 1087 ft Distance traveled (over 50'):2763 ft Flaps 30% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 14 41 2350 0 Rotation 23 59 2430 0 Lift off 32 71 254016 42 75 257064 288 fpm Distance traveled: 1009 ft Distance traveled (over 50'):2529 ft Using JSBSim's IO-320 and Propeller Flaps 0% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 11 40 2500 0 Rotation 18 63 2625 0 Lift off 23 74 2717 4 Engine over red-line 33 89 2830 145 846 fpm Distance traveled:827 ft Distance traveled (over 50'):2191 ft Flaps 30% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 11 39 2500 0 Rotation 18 59 2600 0 Lift off 23 77 2696 8 Engine at red-line 33 80 277076 408 fpm Distance traveled:717 ft Distance traveled (over 50'):1951 ft [1] The aim of the script was to get off the ground asap then lower the nose to gain airspeed. It does not try to establish a best climb speed. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p cockpit improvement
Sorry to respond to myself, but wanted to add some detail: Mass Properties Report (English units: lbf, in, slug-ft^2) WeightCG-XCG-YCG-Z Base Vehicle 1500.041.0 0.036.5 0 Pilot 180.036.0 -14.024.0 1 Co-Pilot 0.036.014.024.0 2 Left Passenger 0.070.0 -14.024.0 3 Right Passenger 0.070.014.024.0 4 Baggage 0.095.0 0.024.0 0 Fuel 100 56-11259.4 1 Fuel 100 56 11259.4 Total:1880.042.1-1.337.7 The CG-X arms should match what's in the TCDS and POH. The propeller file also does not match between JSBSim and FlightGear. JSBSim has the same tables, but they were commented out and replaced with new tables. Using a script I wrote to simulate a softfield takeoff technique[1], I see the following: datafiles as they are in FGDATA: Flaps 0% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 11 40 2332 0 Rotation 17 59 2430 0 Lift off 22 71 2525 8 32 83 262184 456 fpm Flaps 30% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 19000 Brake Release 11 40 23300 Rotation 17 58 24230 Lift off 23 67 2500 14 33 75 2565 90 492 fpm Using JSBSim's IO-320 and Propeller Flaps 0% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 9 39 2500 0 Rotation 13 58 2600 0 Lift off 23 84 280050 Engine over red-line 33 98 2875 200 900 fpm Flaps 30% Time Speed RPMHeightEvent (s)(knot) (ft agl) 0 0 1900 0 Brake Release 9 39 2500 0 Rotation 12 53 2600 0 Lift off 18 70 268015 23 77 2800 130 Engine over red-line 33 87 2830 216 516 fpm [1] The aim of the script was to get off the ground asap then lower the nose to gain airspeed. It does not try to establish a best climb speed. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p cockpit improvement
On Sunday 18 December 2011 04:02:01 Martin Spott wrote: > Patrick Callahan wrote: > > What can be said about the flight dynamics of the C172P model? > > Is it accurate? If not, how could it be improved? > > The response varies _much_ depending on whom you ask :-) > Personally I'm quite confident with FlightGear's flight dynamics, but > there's always room for improvement and if you know someone who's > flying the real one (maybe you're evn doing yourself), take a > stopwatch, pen and paper and record climb rates at certain weather > conditions and power settings and the like. > > Note that there are many, many different variants of the real one, > therefore claims like "it climbs too fast" might be rather moot the > smaller the deviation gets, because it depends much on the weight > (which might depend a lot on the installed equipment) and the condition > of the aircraft. > > Just an idea - cheers, > > Martin. I just noticed the c172p.xml (FDM) in FGData doesn't match the one in JSBSim. The one in JSBSim has propeller induced effects added in. Also, the FDM, by default, Has one 180 lb pilot, no other passengers and no luggage. It also only has 200 pounds of fuel and a capacity of 370 lbs. So, it is very lightly loaded. That could be why some observe that it climbs too well. Ron -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
On Friday 09 December 2011 16:49:14 HB-GRAL wrote: > Am 08.12.11 13:36, schrieb HB-GRAL: > > Hi all > > Hi again > > About marking "closed" airports in apt.dat: > > - marking the name with "[X] " might be closer to charts I guess and > most airports marked as closed in apt.dat comes with the x > - removing x and marking with "(closed)" at end of name is possible in > most cases without having < 40 chars, but this is some kind of "new > convention" ? > - FAA marks closed airports with "Cl" > > What do you prefer for the apt.dat names ? > > Cheers, Yves > > Attached: Log of running "close" option in script. Means: replacing > names with names from ourairports.com, marking with [X] where it is > marked "closed" in ourairports database. And I'd like to request again that we gunzip apt.dat in fgdata. Especially if we're going to start making changes to it. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
On Thursday 08 December 2011 07:07:58 Geoff McLane wrote: > I guess the only thing is concerning 'closed' > airports. Should they be in apt.dat at all? > > But if they are retained for 'historic', or > other purposes, it would be good if they were > all consistent... Just because an airport is 'closed' does not mean the runways no longer exist... The Gimli Glider incident comes to mind. http://en.wikipedia.org/wiki/Gimli_Glider. Even if the runways are removed and built over, often outlines are visible from the air for years after the airport is removed. See http://www.airfields-freeman.com/ for some examples. Ron -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] turbine inlet temperature in the seneca (TIT)
On Tuesday 06 December 2011 07:39:48 Torsten Dreyer wrote: t. > > Ron Jensen is the master of the JSBSim piston engine code. IIRC he has > the supercharger model on his backlog, maybe TIT will be part of his > solution.. The current supercharger code is old, and strictly RPM based, and I don't have a good solution. The EGT calculations changed slightly in the last (2.5) release, and will change again (already in git) in the next release, so they may be more accurate to use as a base for TIT. As I understand it, TIT is exhaust gas temperature measured before the turbo and EGT is exhaust gas temperature measured after the turbo, so TIT will be higher than EGT. The temperature difference should be somewhat proportional to the boost ratio. The more boost being produced, the higher the back-pressure in the turbine impeller, and higher pressure implies higher temperature. Ron -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
On Monday 28 November 2011 11:20:03 Eric van den Berg wrote: > On 11/28/2011 06:14 PM, Adrian Musceac wrote: > > On Monday, November 28, 2011 18:31:42 Eric van den Berg wrote: > >> For GA (what I have handy right now): > >> The good old Garmin 400 series: VOR/LOC:-103.5dBm, GS:-87dBm > >> Avidyne (EntegraII): VOR: 5uV, LOC and GS: 10uV > >> > >> www.repeater-builder.com/measuring-*sensitivity*/*dbm*2uv.pdf > >> /for conversion table!/ > >> > >> The Avidyne is TSO minimums if I remember correctly. Their units tend to > >> depend on GPS (and thus do not care much for radio navigation). > >> > >> Airline stuff goes down to like 0.5uV (so much more sensitive and > >> expensive). They can receive a VOR signal at FL300 at quasi-optical > >> range! > > > > Thanks, that is useful data! From what I could gather from different > > sources on the internet, typical VOR ground equipment operates with > > around 100-200 W ERP, am I correct? > That I do not know. But I do know there are long-range and short-range > VOR-s with significantly different output levels. Not sure how to > determine the difference easily. > For NDB-s it is more easy. The short range ones are on or near the > threshold and at the FAP typically. The nav.dat file contains 'range' in nm for the nav-aid. http://data.x-plane.com/file_specs/Nav740.htm Perhaps you could use some heuristic to create a reasonable power level to meet the published range? Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sunday 06 November 2011 13:35:11 Anders Gidenstam wrote: > Now that we have per-aircraft repositories I plan to add my "source" > material (blender, svg, datcom, octave, gerris etc files) below a dev > directory in the aircraft's repository. Probably further structured in > FDM, models, ... subdirectories. > > If we use a small set of names (I'd suggest dev, development or src) for > the base directory of such files it shouldn't be too hard to make the > aircraft packaging script(s) omit these files from the release .zip > files. I do this now with a folder I call Resources/ in the root of the aircraft directory. I also make a Resources/Local which I add to .gitignore so I can keep non-gpl data with the aircraft on my hard-drive but out of the repository. Ron -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
On Tuesday 18 October 2011 15:56:54 Cedric Sodhi wrote: > On Tue, Oct 18, 2011 at 09:46:58PM +0200, Gijs de Rooy wrote: > >Hi all! > > > >> Cedric wrote: > >> ManDay, on behalf of the Split-Team ^^ > >> > >> ThorstenB wrote: > >> I don't think this is what we agreed upon. > > > >I'd like to mention that Cedric did not wrote his email "on my behalf" > > nor on Jorg's. > > Hello, > > I apologize for wrongly inserting the suggestion to dissolve the repos > "on your behalf". I think the other parts of the E-Mail, the description > etc, were very well composed on your behalf, though. > > As for the topic brought up here, I sense a bit of sentimentalism > clouding the technical judgment of some. > > Fact is, that quite a few aircrafts of the old FGDATA are nowadays > developed elsewhere. I recall at least having witnessed this twice, > although I've only tried a few airplanes. If I recall correctly, skyop's > magnificant Bombardier is one of those planes which are developed > launchpad and is only represented in FGDATA-Airplanes for "historical > reasons". > > Regardless, your arguments why a central repository would be an > advantage, minus the sentimental "it has always been like that" parts, > esp. the one about authors joining and leaving, are more or less > orthogonal to the philosophy of the development structure which you > employ: Git and Gitorious. > > A central facility, which collects all planes, yes, that makes sense. > Actually, I see not how such thing could possibly be forgone. But > forcing all aircraft development under the patronage of the core > developers is without any practical footing. > > You are not helping anyone, nor are you supporting GPL. > > If people want to publish under the GPL, they will do so. If not, they > wont. Regardless of whether you coerce them to publish their planes in > your "master-repository", but only as GPL. > > Neither do you provide any more "guarantee" by herding developers into > your central repository. You are only patronizing them. You cannot > guarantee for someone else's property. And if it's not their property for > it's GPL, you can always keep yourself a backup-copy or a clone of their > repository, if you are worried about guarantees. > > Not only are all these alleged advantages pretty much contrived, there > are also disadvantages in urging people to play in your opera rather > than their own. Restrictions are always harmful to voluntary work. If I, > for example, am a LP user and you are trying to lure me "come, come to > us, here is where the good things happen" to your repository, I will > rather turn away - as opposed to an OPEN development structure where > people are encourage to develop whereever, however they want and simply > announce their contribution centrally. > > History has shown what that concept of a centralized "master-repo" has > lead to: A thick jungle of half-finished, unmaintained and completely > abandoned planes, happily mixed with high-quality planes, relicts of > planes which have long been migrated to development elsewhere and > practically everone has lost orientation in your "master-repo". > > This is not how Git works. This is not how modular contribution on open > software works. This is not how Gitorious works. It's most likely > counter productive, as has been the unnavigable jungle of planes in the > first place. > > In a positive creative development structure you leave the contributors > their freedom. > > "Contribute your planes!" rather than "Come to Gitorious, ask for our > permission to get your repository, work under our supervision! Work, > work, my busy bees, and make us planes for our big master-repository!" > > ...to be equally provocative. > > > kind regards, > ManDay > My own, personal reasons for developing my planes 'elsewhere' and having them migrated into the master repository is because I do not have access to the master repository. I would/will happily migrate all of my aircraft work to fg_aircraft and remove the old repositories if I have commit access to my planes. I think Gjis has the correct sense: if my aircraft is in the master repository, I expect the code developers to take some care that it will not bit-rot because they make a change. If the aircraft is elsewhere, GPL or not, the code developers do not have that obligation. Also, having an aircraft in the "common" repository invites others to join in and make changes. That is how I got started in this whole mess in the first place. $0.02 Thanks, Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Fl
Re: [Flightgear-devel] Query about groundradar Instrument module
On Thursday 29 September 2011 14:32:54 Robbo wrote: > Hi, > > I am trying to familiarise myself with Flightgear's source code so that I > may try and contribute. I am currently looking at the 'groundradar' > instrument module and there is something within that is causing me some > confusion. > > Essentially, there is a 'texture' declared as follows: > static const char* default_texture_name = > "Aircraft/Instruments/Textures/od_groundradar.rgb"; > > This is then used by the following method: > void GroundRadar::createTexture(const char* texture_name) > > in the following way: > FGTextureManager::addTexture(texture_name, getTexture()); > > Now all is good at this point until I go and look for this file, which i > expected to find in data/Aircraft/Instruments/Textures/, however, this file > does not appear there, nor does it appear anywhere else on my filesystem > either. > > I thought, well maybe the code is not actually using this texture, since > its a 'default_texture', however, when i change the name to point to > something else which also does not exist, then, the once black background > becomes white! > > So I am assuming that this file MUST be somewhere, but I have no idea where > it is, can anyone assist me with this? > > Thanks > > Robbo Definitely not my area, but... The hint for me was the call 'createTexture()' opposed to load or get Texture(). I believe we are doing a render-to-texture thing. If you grep for Aircraft/Instruments/Textures/od_groundradar.rgb in fgdata/Aircraft you get many hits like: ATC/radar-screen.xml: Aircraft/Instruments/Textures/od_groundradar.rgb So, if I understand things correctly, the models are asking for a texture by name, which is created by GroundRadar::createTexture() instead of being loaded from disk. Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
On Tuesday 27 September 2011 15:53:26 Curtis Olson wrote: > a heavier than air balloon ... Would that be a Led Zeppelin? :) Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On Sunday 25 September 2011 16:46:32 Scott wrote:
> From: Scott
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] latest Git next, endless loop from
> FGATCMgr and missing JSBsim fuel-used property
> Date: Mon, 26 Sep 2011 08:37:06 +1000
>
> On Sun, 2011-09-25 at 13:49 -0600, Ron Jensen wrote:
> > On Sunday 25 September 2011 01:36:25 Scott Hamilton wrote:
> > > Greetings,
> > >
> > > I've noticed two small problems with the current Git
> > > "next" (as at 2011-09-25), is anyone else seeing these?
> > >
> > > 1. the JSBsim
> > > per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has
> > > disappeared
> >
> > I see it in the code, and in my fgfs. It should be automatically created
> > for every JSBSim engine. What aircraft are you flying?
>
> Hi ya Ron,
>
>I was flying the A380 and thought it was not being created as the
> A380 has a JSBsim Post function to convert it to fuel-used-kg, so I
> thought that was creating the fuel-used-lbs when reading it.
>I then tried the 747-400 and I see fuel-used-lbs is being created as
> zero, but is not been updated, it remains at zero once you start the
> engines, so that looks like the problem, it is not being updated.
>
>So I notice that when I did a 'git pull next' yesterday, a whole lot
> of FDM/jsbsim/propulsion changes, it was probably about 3 - 4 weeks
> prior that I did the last git pull next, when fuel-used-lbs property was
> updated correctly for each engine.
>
>
>
>cheers
> S.
Ah, the fuel consumption code was refactored and the mechanism for setting
that property was removed. The attached patch, which is now in JSBSim head
fixes the issue.
Sorry,
Ron
>From 67779f1d563d6d1661cb5295c210c6ac67ef74b4 Mon Sep 17 00:00:00 2001
From: rjensen
Date: Sun, 25 Sep 2011 17:53:04 -0600
Subject: [PATCH] Make the total fuel expended counter work again.
---
src/models/propulsion/FGPiston.cpp|1 +
src/models/propulsion/FGTurbine.cpp |1 +
src/models/propulsion/FGTurboProp.cpp |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/models/propulsion/FGPiston.cpp b/src/models/propulsion/FGPiston.cpp
index d055056..f8baaa8 100644
--- a/src/models/propulsion/FGPiston.cpp
+++ b/src/models/propulsion/FGPiston.cpp
@@ -481,6 +481,7 @@ void FGPiston::Calculate(void)
double FGPiston::CalcFuelNeed(void)
{
FuelExpended = FuelFlowRate * in.TotalDeltaT;
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
diff --git a/src/models/propulsion/FGTurbine.cpp b/src/models/propulsion/FGTurbine.cpp
index 5b676ed..b86bf76 100644
--- a/src/models/propulsion/FGTurbine.cpp
+++ b/src/models/propulsion/FGTurbine.cpp
@@ -385,6 +385,7 @@ double FGTurbine::CalcFuelNeed(void)
{
FuelFlowRate = FuelFlow_pph / 3600.0; // Calculates flow in lbs/sec from lbs/hr
FuelExpended = FuelFlowRate * in.TotalDeltaT; // Calculates fuel expended in this time step
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
diff --git a/src/models/propulsion/FGTurboProp.cpp b/src/models/propulsion/FGTurboProp.cpp
index 41f7967..7def4fb 100644
--- a/src/models/propulsion/FGTurboProp.cpp
+++ b/src/models/propulsion/FGTurboProp.cpp
@@ -410,6 +410,7 @@ double FGTurboProp::CalcFuelNeed(void)
{
FuelFlowRate = FuelFlow_pph / 3600.0;
FuelExpended = FuelFlowRate * in.TotalDeltaT;
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
--
1.7.4.4
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On Sunday 25 September 2011 01:36:25 Scott Hamilton wrote: > Greetings, > > I've noticed two small problems with the current Git > "next" (as at 2011-09-25), is anyone else seeing these? > > 1. the JSBsim > per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has > disappeared I see it in the code, and in my fgfs. It should be automatically created for every JSBSim engine. What aircraft are you flying? Thanks, Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Toe brakes (was: Direct Draw Surface Scenery Textures)
They are homebrewed. The guts came out of a Saiteck 290 Pro joystick and the pedals are Thrustmasters. An hour with a soldering iron would fix the reversed pot, but 30 seconds in a text editor made it work just fine. :) http://www.jentronics.com/fgfs/simpit/pedal.jpg On Sunday 25 September 2011 03:20:23 Durk Talsma wrote: > Hi Ron, > > Thanks for reporting. Which set of pedals are you using? For me, both > brakes report -1 when not pressed and 1 when pressed. > > I am using the saitek pro pedals. When looking at the raw device output > (using jstest /dev/input/js[01]), I see that (usually), the toe brakes > output is only -32767 or +32767 (with no intermediaries). I also typically > find that when I first plug in the pedals, js_demo reports losing the > device. > > As mentioned, this is mostly how it is reported. Sometimes the correct > values are reported, which makes me believe that I'm either facing a > hardware problem (which went undetected in older kernels), or the more > recent kernels don't know how to handle the Saitek pedals. > > In any case, I might want to try downloading a debian live CD to see what > kind of behavior I'm getting there (or test an older Suse installation). > > Cheers, > Durk > > > I just looked at js_demo with my toe brakes and they show the same > > behavior, range is +/-1, left brake sense is reversed. > > > > Debian Linux 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 > > GNU/Linux > > > > I have this as a configuration: (add an offset so the range is 0..2 then > > multiply by 0.5) > > > > > > Left Brake > > > > property-scale > > /controls/gear/brake-left > > -1.0 > > -0.5 > > > > > > > > > > Right Brake > > > > property-scale > > /controls/gear/brake-right > > 0.5 > > 1.0 > > > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
On Friday 23 September 2011 14:57:34 Durk Talsma wrote: > On 23 Sep 2011, at 00:43, ThorstenB wrote: > > Hmm, but this actually means you have a brake problem after all. Only > > the brake temperature is simulated - smoke is triggered for overheated > > disc brakes. It's almost impossible that the parking brake is set > > (unless your both, deaf and blind...) but it seems like your brakes are > > slightly tightened after all. That's a safety critical issue - better > > tell maintenance personnel to check your flight gear - maybe the pedals > > are stuck... ;) > > It looks like this is indeed what is happening. I've been having some > calibration problems ever since upgrading to Suse 11.4, and it looks like > the normalized values for the toe-brakes can only be 0 or one, being zero > when I'm not touching them. I wasn't aware of that yesterday, but it looks > like the toe brakes should operate in the range of -1 to 1, so that 0 means > that the breaks are half pressed. I just looked at js_demo with my toe brakes and they show the same behavior, range is +/-1, left brake sense is reversed. Debian Linux 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 GNU/Linux I have this as a configuration: (add an offset so the range is 0..2 then multiply by 0.5) Left Brake property-scale /controls/gear/brake-left -1.0 -0.5 Right Brake property-scale /controls/gear/brake-right 0.5 1.0 > It looks like both my FlightGear desktop and my old laptop (both running > opensuse 11.4) are showing the same problem, while the pedals are working > correctly on my (work) macbook; obviously, I would almost add. > > I hope I can get this to work, because this looks like a nagging little > problem. > > If not, I might be facing a kernel upgrade, or downgrade > > Cheers, > Durk > > > In any case, sorry about the noise... > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
On Thursday 22 September 2011 16:43:32 ThorstenB wrote: > On 23.09.2011 00:09, Durk Talsma wrote: > > I did recalibrate my joystick, but upon checking that, the brake > > function appears to work normally. > > as shown here, I did have a severe tire problem after takeoff. :-) > > > > http://www.durktalsma.nl/FlightGear/fgfs-screen-064.png > > Hmm, but this actually means you have a brake problem after all. Only > the brake temperature is simulated - smoke is triggered for overheated > disc brakes. It's almost impossible that the parking brake is set > (unless your both, deaf and blind...) but it seems like your brakes are > slightly tightened after all. That's a safety critical issue - better > tell maintenance personnel to check your flight gear - maybe the pedals > are stuck... ;) > > cheers, > Thorsten Brakes aren't really hot until the tires burst into flames. Been there, done that. :) Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
On Friday 09 September 2011 11:33:17 Curtis Olson wrote: > Hi Yves, > > The general approach that genapts uses this. > <...> > We get to pick the order we process the airport surface objects, so we pick > the runways first, and probably the biggest runways before the smaller > runways. Then the bigger taxiways before the littler taxiways, etc. > Biggest/most important to smallest, least important. <...> This is actually incorrect handling. Taxiways should be processed in order they appear in the 8.10 data file. I believe it has been fixed in Terragear-cs to behave this way. A heuristic approach based on size prevents an airport artist from using the taxidraw ordering feature from hinting at the correct orientation. You don't always want the longest taxiway on top. Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On Monday 05 September 2011 10:10:27 Curtis Olson wrote: > Are there any cmake based build instructions available anywhere? I'm not > seeing them. > I'm just hoping the cmake jocks will put themselves in the position of > non-cmake jocks and help ease the transition from multiple fronts for many > of our different classes of users/developers. > > Thanks! > > Curt. Let me echo what Curt said. I don't like CMake that much, because it seems overly complicated. HOW DO I BUILD FLIGHTGEAR NOW? Thank you, Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Comment (was New aircraft: SF-25)
On Monday 15 August 2011 11:18:53 Gary Neely wrote: > Looks like a great start. The first thing I would do before anything > else is make sure your CG is positioned reasonably. In your SF-25, the > CG is much too far back; given the forward-swept wings, it looks to be > about a meter behind MAC: > > E:\FlightGear projects\sf25b>yasim sf25b-yasim.xml > Solution results: Iterations: 1292 > Drag Coefficient: 10.955851 >Lift Ratio: 291.677826 >Cruise AoA: 1.469686 >Tail Incidence: 2.793443 > Approach Elevator: -0.014301 >CG: x:-0.900, y:-0.000, z:0.284 > > Inertia tensor : 1831.357, -0.000, 78.171 > [kg*m^2] -0.000, 2075.542, 0.000 > Origo at CG 78.171, 0.000, 3856.738 > > The command-line YASim solver is showing CG at x=-0.9, well behind the > wing's root chord position at x="-0.371". I took a look at the YASim solver today, first comparing the Inertial tensor with the inertias coming out of aeromatic. Not too far apart, but the 2 yasim aircraft I looked at were both 50% higher than the aeromatic numbers. Then I took a look at the -g switch and was rather shocked at the curves yasim generates. It generates CL, CD and L/D. My plot software computes force as (lift^2+drag^2)^0.5. Lift and drag are perpendicular by definition so this gives the total force in the lift/drag plane. I made 3 plots with Tat's A6M2 and Helijah's Katana and Gloster-Meteor models: http://www.jentronics.com/fgfs/temp/yasim/yasim-A6M2.png http://www.jentronics.com/fgfs/temp/yasim/yasim-katana.png http://www.jentronics.com/fgfs/temp/yasim/yasim-glostermeteor.png And then I loaded some data I had from a NACA 4 digit 0015 airfoil into the same plot definition: http://www.jentronics.com/fgfs/temp/yasim/naca0015.png I was pretty shocked to see the YASim charts drag numbers all seem to fall off at stall. This is counterintuitive to me, I expect drag to increase at stall, that is what keeps the speed low during the stall. Also, the lift/drag (L/D) ratio is actually the tangent of the angle the aerodynamic force is acting in. On the real airfoil it rapidly approaches 0 after the stall because the force is acting nearly parallel to the free stream velocity and drag dominates the ratio. This seems not to be the case with the YASim models. Thanks, Ron -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lat Lon vs. Deg Min
On Thursday 28 July 2011 18:54:21 HB-GRAL wrote: > Hi Geos > > Can someone explain me why we use > > lat="N37 42.807" > lon="W122 12.963" > > in parking.xml and groundnet.xml > > and not lat/lon formats like we use it for runways and it is used in > apt.dat and other data files ? > > Thanks, Yves Because parking.xml/groundnet.xml predates everthing else, but decimal degrees are much nicer to work in. Ron -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Definition of "toOsg"
On Monday 04 July 2011 08:38:26 John Wojnaroski wrote:
> toOsg
Converts SG Vectors to OSG Vectors
simgear/simgear/math/SGVec2.hxx
simgear/simgear/math/SGVec3.hxx
simgear/simgear/math/SGVec4.hxx
toOsg(const SGVec2d& v)
{ return osg::Vec2d(v[0], v[1]); }
--
toOsg(const SGVec2f& v)
{ return osg::Vec2f(v[0], v[1]); }
--
toOsg(const SGVec3d& v)
{ return osg::Vec3d(v[0], v[1], v[2]); }
--
toOsg(const SGVec3f& v)
{ return osg::Vec3f(v[0], v[1], v[2]); }
--
toOsg(const SGVec4d& v)
{ return osg::Vec4d(v[0], v[1], v[2], v[3]); }
--
toOsg(const SGVec4f& v)
{ return osg::Vec4f(v[0], v[1], v[2], v[3]); }
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
On Saturday 02 July 2011 17:52:23 Chris Wilkinson wrote:
> I re-read the messages on starting and I see...
>
> loadxml: reading '' denied (unauthorized access)
/**
* An fgcommand to allow loading of xml files via nasal,
* the xml file's structure will be made available within
* a property tree node defined under argument "targetnode",
* or in the given argument tree under "data" otherwise.
*
* @param filename a string to hold the complete path & filename of an XML file
* @param targetnode a string pointing to a location within the property tree
* where to store the parsed XML file. If is undefined, then the
* file contents are stored under a node in the argument tree.
*/
static bool
do_load_xml_to_proptree(const SGPropertyNode * arg)
{
SGPath file(arg->getStringValue("filename"));
if (file.str().empty())
return false;
if (file.extension() != "xml")
file.concat(".xml");
std::string icao = arg->getStringValue("icao");
if (icao.empty()) {
if (file.isRelative()) {
file = globals->resolve_maybe_aircraft_path(file.str());
}
} else {
if (!XMLLoader::findAirportData(icao, file.str(), file)) {
SG_LOG(SG_IO, SG_INFO, "loadxml: failed to find airport data for "
<< file.str() << " at ICAO:" << icao);
return false;
}
}
if (!fgValidatePath(file.c_str(), false)) {
SG_LOG(SG_IO, SG_ALERT, "loadxml: reading '" << file.str() << "' denied
"
"(unauthorized access)");
return false;
}
This fragment from src/Main/fg_commands.cxx is the source of that error
message. If you look closely, you'll see a file name is supposed to be in
those quote marks. A file name that appears not to exist in the current case.
It to me, for that to happen globals->resolve_maybe_aircraft_path(file.str())
is returning a null. Is FG_AIRCRAFT set to a valid path or unset?
Also, this is apparently nasal related. Is the path allowed in Nasal/IOrules?
Ron
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A couple of random oddities
On Thursday 30 June 2011 04:41:13 AJ MacLeod wrote: > On Wed, 29 Jun 2011 23:28:42 +0100 > > "Vivian Meazza" wrote: > > Further research indicates that the F1A, modeled here was NOT capable of > > M2.0 at 36000ft. M1.9 seem more likely. Moreover, due to structural and > > stability problems the F1A was operationally limited to M1.7 or > > approximately 700KIAS. We have pushed a small change in Mach drag to > > model this better. Ron will look at the Mach stability issue a bit later. > > Thanks Vivian (and Ron)... It's been so long since I did the model that > I've forgotten all the relevant figures; I know it matched all the > descriptions of flight behaviour I could get hold of at the time fairly > well, but I've not really flown the model since then. There's probably > more performance data available for the later marks which is possible > confusing people. > > Cheers, > > AJ I've been glancing through the configuration files for this aircraft. There's several thing written in Nasal I'd like to port over to JSBSim systems: - Flaps function based on voltage - Flaps retract automatically above 250 knots - Airbrakes function based on voltage - Airbrakes retract automatically above mach 1.3 - Move drag chute to an external force and do much more of it in JSBSim - Refuel, use the internal JSBSim refuel mechanism instead of nasal interpolations. - Landing gear function based on voltage - Landing gear will not retract below 150 knots - Landing gear emergency will lock gears down I also plan to make the FDM more 360 degree capable as well as making it less yaw stable above mach 1.7 Thanks, Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
On Friday 01 July 2011 00:30:11 Erik Hofman wrote: > On Thu, 2011-06-30 at 10:11 -0600, Ron Jensen wrote: > > There have been a few bug fixes to JSBSim since this sync, notably: > > > > src/FDM/JSBSim/models/flight_control/FGActuator.cpp > > src/FDM/JSBSim/models/flight_control/FGFCSComponent.cpp > > src/FDM/JSBSim/models/flight_control/FGFCSComponent.h > > src/FDM/JSBSim/models/flight_control/FGSwitch.cpp > > src/FDM/JSBSim/models/propulsion/FGTank.cpp > > > > We don't want a whole-sale sync but if these six files were updated, that > > would be great. > > Since the addition of the new environment code to JSBSim I've been > hesitating to sync again but only copying these files doesn't seem to > break anything so it's pushed to git. > > FGFCSComponent.h and FGSwitch.cpp don't seem to have any updates. > > Erik You're right, those two fixes went in last time. I missed that, sorry. Thanks for updating these. Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
On Friday 17 June 2011 01:30:45 Erik Hofman wrote: > On Thu, 2011-06-16 at 22:23 -0500, Jon S. Berndt wrote: > > I am very close to committing the new atmosphere code (and the new > > FGWinds) to JSBSim cvs. However, it would be prudent to first get a > > glitch or two fixed and then grab that code and put that in FlightGear > > first, just in case the newer atmosphere and winds code causes problems. > > Alright, the current state of JSBSim has been pushed to FlightGear GIT. > > Erik There have been a few bug fixes to JSBSim since this sync, notably: src/FDM/JSBSim/models/flight_control/FGActuator.cpp src/FDM/JSBSim/models/flight_control/FGFCSComponent.cpp src/FDM/JSBSim/models/flight_control/FGFCSComponent.h src/FDM/JSBSim/models/flight_control/FGSwitch.cpp src/FDM/JSBSim/models/propulsion/FGTank.cpp We don't want a whole-sale sync but if these six files were updated, that would be great. Thanks, Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A couple of random oddities
On Wednesday 29 June 2011 05:51:07 AJ MacLeod wrote: > On Wed, 29 Jun 2011 10:39:55 +0100 > > Vivian Meazza wrote: > > > * English Electric Lightning: I believe the plane should be able to > > > reach Mach 2 around 36.000 ft in level flight - even in a descending > > > pattern, I was never able to reach above Mach 1.7 - is there a problem > > > with the FDM? > > > > The author is inactive at the moment. Perhaps he can be persuaded to give > > this fine model a bit of a work-over. > > The author is a bit too active, which sadly doesn't leave any time for > Flightgear :-( The instruments I'll try and fix myself, but do any JSBSim > experts have any ideas on what might have changed the behaviour of the FDM > model? It worked OK "before"... though I have no idea when that changed. > > Cheers, > > AJ I don't know of any changes that would have impacted your model. We did fix the thrust tables a few months back... Its really hard for me to see individual aircraft histories in git, but we probably fixed the elevator drag issue in this FDM as well. If you remember, aeromatic configured CDde to go negative at times causing false thrust. I looked at this model in JSBSim stand-alone and saw three sources of drag at mach 2.06 and 36,000 ft: aero/coefficient/CDalpha = 12993.134843 (pounds force) aero/coefficient/CDmach = 5197.253937 (pounds force) aero/coefficient/CDde = 8567.342560 (pounds force) A combined 26,700 pounds of drag. Our two engines in full reheat at mach 2.06, 36,000 feet put out a combined thrust of 20,200 pounds of thrust. Leaving 6,500 pounds of drag unbalance, so we slow down. The CDde coefficient is 0.04 * |elevator-pos-norm|. This is an aeromatic default value for all aircraft. Since the Lightening F.1a has an all moving tailplane not an elevator, this number is way too big. Changing it to 0.008 yields an output of: aero/coefficient/CDde = 1787.161206 (pounds force) Or a combined 20,000 pounds of drag. Just about matching what our engines produce. Thanks, Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Data flow from controls to FDM
On Sunday 26 June 2011 14:37:09 Jon S. Berndt wrote: > > -Original Message- > > From: Alan Teeder [mailto:***] > > > > I have some questions regarding how data gets from the joystick, keypad > > etc to the fdm. No doubt I will feel foolish when it is pointed out that > > it is documented somewhere, but to date I have had to rely on > > experimentation and copying of XML/Nasal code from existing aircraft. > > > > 2. Is there any scaling, limiting or other filtering ? > > > > TIA > > > > Alan > > This was a much-discussed topic a few months ago. If I'm not mistaken, I > think that the consensus was that the FDM should assume that it gets the > raw signal from the joystick - even though there is some processing of the > joystick hardware signal that is thought to be effectively unavoidable. > > Jon As was pointed out, the joystick, keyboard, mouse etc value is interpreted and processed by flightgear to become the properties in /controls/flight/(whatever). In general (there are exceptions) JSBSim.cxx copies those over to fcs/(whatever)-cmd-norm every flightgear frame. Every JSBSim frame the value from fcs/(whatever)-cmd-norm, where (whatever) is propulsion and gear controls, is moved to fcs/(whatever)-pos-norm then the JSBSim systems code runs which may or may not overwrite fcs/(whatever)-pos-norm with a calculated value. The the JSBSim autopilot code runs (different from the Flightgear autopilot). Finally the FCS section code runs. See FDM/JSBSim/models/FGFCS.cpp for details. JSBSim generally gets 4-8 frames for every FlightGear frame so that it runs at a consistent 120 frames/second. Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Saturday 25 June 2011 12:28:14 David Slocombe wrote: > Hi, > > Currently I do not even have a working fg on my machine, but I continue > to peek at the flightgear-devel list occasionally. Today I saw this > discussion of moving the aircraft directories to individual SVN repos > instead of git. The major drawback of GIT over CVS and SVN in this instance is GIT treats the repository as an atomic whole. CVS and SVN have the ability to provide partial checkouts, that is you could update a single directory or even just a single file without updating the whole thing. This becomes important when the repository grows into the multigigabyte size range. Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
On Sunday 19 June 2011 10:50:01 John Denker wrote: > On 06/19/2011 06:46 AM, Jon S. Berndt wrote: > > Maybe I've gone wrong somewhere here, but something similar might work. > > Also, in situations like a flat spin or tail slide this probably falls > > apart! > > Let's postpone discussion of exotic flight conditions such as flat > spins and tail slides. There are much more prosaic situations that > need to be addressed. Let's start by getting the aircraft to behave > properly when >a) _taxiing_ with a crosswind and/or tailwind, and >b) _landing_ and _taking off_ with a crosswind and/or tailwind, > > These seem like basic and fundamental features. > The value of these features can hardly be exaggerated. For example, > according to page 4-3 of the POH the "maximum demonstrated crosswind" > for a C-172 is 15 knots. >c) _engine out_ (asymmetric thrust) in a twin, We already model asymmetric thrust. >d) simple _inverted flight_ ... not an inverted flat spin, just > plain old inverted flight, such as people routinely do in a > Cessna 150 Aerobat. Aerodynamically, inverted flight is already possible. >e) The effect of propwash on trim and on elevator authority. > This is a big deal in some aircraft, including the 152/172/182 > family. So, I set up a soft field take off in JSBSim stand-alone with a 15 knot crosswind using the c172p that is in FGFS git: Rotation 13 seconds @41 knots 375 feet Lift off 19 seconds @58 knots 800 feet Distance over 50' 2150 feet Heading Error >45 degrees Then I added the induced thrust which was the topic of this thread in the first place: Rotation 1 seconds @3 knots 3 feet Lift off 20 seconds @55 knots 900 feet Distance over 50' 2550 feet Heading Error <3 degrees Rudder deflection 34% Thanks, Ron -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday 19 June 2011 17:55:25 Hal V. Engel wrote:
> On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote:
> > http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg302
> >08 .html gui.menuBind("radio", "dialogs.Radio.open()");
>
> Thanks I knew I saw something about this on the list but I coundn't find
> the emails that covered it. When I try to use it it fails when I click on
> the menu item.
>
> Here is my code:
>
> var radio = gui.Dialog.new("sim/gui/dialogs/SCR-522C/dialog",
>
> "Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml");
> gui.menuBind("radio", "dialogs.radio.open()");
>
> When I select Equipment --> Radios I get the following error message in the
> console:
>
> Nasal runtime error: undefined symbol: dialogs at
> /sim/bindings/menu/bindings[35], line 1
>
> I must be doing something wrong but I don't see what it is. Can anyone
> here spot my error?
>
> Hal
In the example case you are running in the namespace "dialogs" so, in the
setfile you would have:
mynasal.nas
If you have something different, you need something different...
Assuming you load the nasal in this block:
Aircraft/p51d/Nasal/over-ride-flaps.nas
Aircraft/p51d/Nasal/stores.nas
Aircraft/p51d/Nasal/limits.nas
Aircraft/p51d/Nasal/engine-start.nas
Aircraft/p51d/Nasal/sputter.nas
Aircraft/p51d/Nasal/climbrate.nas
Aircraft/p51d/Nasal/gear-doors.nas
Aircraft/p51d/Nasal/gear-lever.nas
gui.menuBind("radio", "p51d.radio.open()");
Ron
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday 19 June 2011 15:04:11 Hal V. Engel wrote:
> I need to over ride one of the default menu items so that I can use a
> custom menu. After some effort I have figured out what needs to be changed
> in the property tree. The code looks like this:
>
> # Disable the menu item "Equipment > radio" so we use our own gui.
> gui.menuEnable("radio",0);
>
> # override default radio menu
> setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",
> "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");
>
> gui.menuEnable("SCR-522C-radio",1);
>
> And this is working. But I am concerned that if the menus should be
> changed (IE. items added or removed) that this would no longer be correct
> and the code will start failing. Is that true? If so ithere a better way
> to do this sort of thing?
>
> Hal
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208.html
gui.menuBind("radio", "dialogs.Radio.open()");
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
On Saturday 18 June 2011 21:00:41 Jon S. Berndt wrote: > Here's an example from Hal's P-51D Mustang. This is from an old version, so > it may have changed by now, but it illustrates the approach. In the > section of the config file - but outside of any > element - is this definition of qbar due to propwash: > > [Note: is shorthand for "value", and is shorthand for "property".] > > > > 0.5 > atmosphere/rho-slugs_ft3 > > > velocities/u-aero-fps > >propulsion/engine/prop-induced-velocity_fps >2.0 > > >2.0 > > > I recently added this function to the A6M2 Zero. I placed it on CYdr (rudder yaw) and dCLdf (flap lift delta) as well as CMde. It makes the plane fly much, much better during the initial takeoff roll. It probably should be used with CMdf (pitch due to flaps) as well. But why are you multiplying propulsion/engine/prop-induced-velocity_fps by 2? > [Note that while this function definition is named "aero/coefficient/Cmde" > it is not really a coefficient, but an actual moment in units of foot > pounds. The "coefficient" part of the name is a holdout from years past.] I prefer to read this as "The reconstituted coefficient" or "The formula containing the coefficient" :) Seriously, I was never confused by the function naming. It helped me along when I was first learning JSBSim, because those are the terms all the textbooks use. Look at FDMs like the c182rg that have had everything renamed to the marginally pendantically correct "FLDe" instead of "CLDe" and "MmDe" instead of "CmDe". I find it ugly and potentially confusing to new users. Thanks, Ron -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Could We Sync JSBSim for 2.3.0, Please?
There are some valuable features in JSBSim now it would be nice to have in the release. Could someone please sync the latest JSBSim into the flightgear code please? Thanks, Ron -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Wednesday 15 June 2011 07:36:51 Csaba Halász wrote: > On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: > > the final GUI bits for a new feature are now in fgdata - the last > > feature addition for the 2.4 release from my part... You can > > download/update scenery directly from FlightGear now (main menu: > > Environment => Scenery). Credit for the idea goes to James - bugs are > > mine ;-). > > For the record, I don't think we are going in the right direction with > this. I personally think more modules should be split out rather than > integrated. For example, all the GUI stuff should be thrown out and left to > a > launcher/control console application. We could then get rid of plib > and avoid the "what gui toolkit to use" controversy (at least for the > core FG). FDM and visualization should also be split, obviously with > multiple instances allowed of either. For the record, and for what its worth, I totally agree with Csaba here. Thanks, Ron -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] modelling an battery powered electric motor MAV
On Friday 03 June 2011 01:49:30 Gaurav Tendolkar wrote:
> I am modelling an battery powered electric motor MAV.
> In JSBsim the battery does not discharge.
>
> 00178 FGElectric::CalcFuelNeed(void)00179 {00180 return 0;00181 }
>
> now i want to write a code where fuel is the power supplied by battery.
> by knowing the total stored energy we will calculate time to discharge.
>
> How do i make the changes to the code come to effect in flightgear ?
Consuming fuel requires a loss of mass. I'm sure you don't intend that, so I
would recommend looking at other methods. Like Curt suggested, you could
create your own system using JSBSim functions (recommend) or NASAL. You can
use these properties to calculate the power consumed by the engine:
propulsion/engine/power-hp
propulsion/engine/propeller-rpm
(These are JSBSim properties, in FlightGear they are preceded by /fdm/jsbsim/)
This code snippet for the JSBSim block will reduce the throttle by the
normalized battery voltage.
Setting the value of (/fdm/jsbsim/)propulsion/battery-volt-norm is left to
you.
propulsion/battery-volt-norm
fcs/throttle-cmd-norm
propulsion/battery-volt-norm
fcs/throttle-pos-norm
Good luck,
Ron
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Moving the Frame-Rate and Left Out Properties.
I just built FG and Simgear from gitorious/next today and I can no longer move the Frame-Rate number or the Left-Out properties. Dialogs still seem to move and resize O.K. Thanks, Ron -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Wanting to build overlays for Video
On Monday 23 May 2011 17:38:20 Jason Cox wrote: > Hi all, > This is way OT as its not flight related but a possible use for > Flightgear. > > I have a friend who is motor sport and just completed a race where he > has taken on board HD video and also has the GPS data from the event. > > I have a plan where I would like to moc up some instruments (speedo and > map) and superimpose them over the video. > > My thought is to make a cockpit with floating instruments and > transparent dash with the scenery being that of the video. Once that is > done I would feed the instruments with the GPS data so that they show > the speed of which the car was traveling at the time. > > Now for the questions. > > 1. Is there a good manual on how to design the layouts for the cockpit? > 2. Could I project the video out the cockpit in place of scenery? > 3. Can I replay GPS data into the instraments and have some sort sync > with the GPS data? > 4. Is it possible? > > Thanks > Jason Cox http://www.youtube.com/user/clolsonus#p/u/65/SAMGnK9ztdA http://www.youtube.com/user/clolsonus#p/u/64/RgK1019Bjno -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote: > I would like to have the old fdm back, maybe it is possible to have another > version with the easy-to-fly-fdm beside the original one. > > Any opinions about, something I missed? > > Heiko Helijah's workflow should make it dead simple to create another -set file, maybe alouette2-easy-set.xml to load the easy fdm. All the settings are in aloutte2-base.xml anyway. My $0.02 Ron -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmosphere
On Tuesday 17 May 2011 21:35:59 Jon S. Berndt wrote: > > What is the requirement from the FlightGear side for an atmosphere > > model? > > I'd like to remove the capability to drive the JSBSim standard > > atmosphere > > model from FlightGear, but first I'd like to get a clear picture of how > > FlightGear users interact with the atmosphere, if at all. > > > > Comments? > > > > Jon > > In other words, this property: > > /environment/params/control-fdm-atmosphere > > Will then be deprecated and have no effect. > > Jon Jon, It is my understanding that this is an either/or situation where we either have the FDM atmosphere model or the FlightGear supplied model based on this value. Flightgear's model can be driven by live METAR data and has variable lapse rates based on temperature and field pressure. Thanks, Ron -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures
On Wednesday 11 May 2011 15:14:01 Csaba Halász wrote: > On Wed, May 11, 2011 at 6:38 PM, Vivian Meazza > > wrote: > > Christian Schmitt wrote > > > >> The stopways still work for me here, so there is maybe something wrong > >> in your fgdata? > > > > I have absolutely up-to-date data and source from Git here - still no > > stopways. Is your data up-to-date? But I suspect that the error is local, > > since there are no other reports of this problem. > > For the record, I don't think I have ever seen any stopways. I have > now checked with fgdata from before the new textures were committed > and the current head - no stopways with either. > > Anybody got a screenshot with stopways? http://www.jentronics.com/fgfs/temp/genapts_stopway01.jpg http://www.jentronics.com/fgfs/temp/genapts_stopway02.jpg http://www.jentronics.com/fgfs/temp/genapts_stopway05.jpg Stopways were added to genapts in January, 2010. Ron -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Monday 25 April 2011 12:10:26 Hal V. Engel wrote: snip > The supercharger model used by JSBSim assumes a turbo charger so the power > and fuel consuption curves are incorrect for an engine driven supercharger > where more horse power (and fuel) are used to drive the supercharger. The supercharger in JSBSim is not very good, but it is engine driven in that the pressure directly varies with engine RPM unlike a turbocharger which varies with mass flow rate and exhaust temperature. The model just does not consume any power. At some point I would like to add a and ability or add functionality to simulate an arbitrary boost device... > Using functions to set VE and BSFC at runtime gives you a way to get fuel > consumption and power curves close to correct but it does take a lot of > effort to get these functions tuned. > > snip snip > this should be fairly easy to setup > since you would only need to do some tuning to figure out the > cooling-factor for the closed and open cowl flaps and then write a simple > function to vary the cooling-factor with the clowl flap control position. Learning to use JSBSim stand-alone greatly simplifies this kind of tuning. It allows you to make multiple, identical runs while varying only a single variable at a time. Ron -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Sunday 24 April 2011 15:00:41 Pavel Cueto wrote: > Hello to all > > I'm developing with a friend the PZL M18B "Dromader" in JSBSim, doing this > first with aeromatic generated data; and now, we are mixing them with real > aircraft data from very reliable sources. However, the engine behavior > seems very different in numbers compared with what we expect from it: > > Engine: ASz-62IRM18 > Max.RPM: 2200 / Min.RPM: 550 > Constant speed propeller > > - The reduction gear ratio of the real engine is 0.687, but writting that > value the engine has too low RPM, that it even can't start. Trying to > "invent" a calculation for the ratio, i got a new 1.45 gear reduction > ratio, but that number still being unaccurate. 0.687 is from the engine to the propeller. To specify from the propeller to the engine use 1/0.687 or 1.456 > In example, according to > engine manual, if RPM are 1900 with a fine propeller pitch, changing the > prop pitch to coarse will reduce the RPM to 1500; but in the model RPMs are > reduced even to 1000 RPM. I guess that FDM needs a ratio number wich are > different to originals, true? No, set the minrpm of the propeller to 1500*0.687 or 1031. This means the propeller will not try to slow the engine below that point. > - The max.RPM of the engine are 2200 RPM. But the model just reach circa > 1600 RPM with full throttle and fine propeller. Your engine power is too low to turn the propeller at the specified speed. No boost as noted below. > - The min.RPM of the engine are 550 RPM. But with min.throttle and coarse > propeller it reach 790 RPM. Your engine power is too high at idle to let the engine slow. > - These values of RPM change and increase when the model starts to move > (!). Yes, there are two effects: 1 - wind through the propeller lowers the load and allows the RPM to increase. 2 - ram air into the engine raises manifold pressure (and power) slightly > It's possible to get RPM over 2000 only when flying, but the min.RPM > turns then too much strong to try sucessfull landings. > > How can i fix each point? > > For better understanding, i'll add the values of my xml files: > > > ENGINE > -- > > 24.21 minmp controls how low you can idle the engine. Our engine model likes really low values for this, and 24.21 inHg is wide open throttle for an unboosted engine at 6000 ft asl. > 41.34 Speaking of unboosted, the model will no longer create fake boost by putting in a large manifold pressure, a supercharger must be specified. > 1823 > 6.10 > 6.87 > 9 > 6.4 > 980 > 4 > 550 > 2200 > 1 > 0 min and max throttle don't do anything anymore > 0.671 1.38 ve is a measure of how much air mass moves through the engine. > > > > PROPELLER > - > > 14.7823 > 129.92 > 4 > 1.45 > 17 > 32 You didn't include the tables, so I can't comment here too much but the min and max pitch must be in the range. The propeller I'm attaching has tables running from -10 to 90 degrees. You can use min pitch to control when the engine reaches 2200 rpm vs manifold pressure and max pitch to control when the propeller is no longer able to keep the engine speed down to 1500 rpm. > 380 380 translates to the idle rpm of 550. You don't want to do that set it to 1031 so the propeller won't load the engine too much. > 1510 2200 * 0.687 is 1511 so maxrpm is good. > 1 > 1 > > (Here is the table in the XMLs) > > > (Here is the table in the XMLs) > > > > > Well, I was needed to ask here, because the documentation available in > JSBSim manual and/or wiki was insufficient to do it for myself. I'll be > very glad to get any info to work. > > Thanks > > --- > PD: What is > "ixx" Ixx is the rotational moment of inertia for the propeller/engine combination. Small numbers accelerate faster but bounce around more. Large numbers accelerate slower and regulate smoother. > "Spark fail drop", Spark fail drop is the amount of power you get for single magneto operation. > "Volumetric efficiency" VE controls how much air goes through the engine at a given RPM. You can use it to fine tune fuel flow at a given manifold pressure/rpm setting. Its partner, BSFC, is the amount of power the engine produces per unit of fuel consumed. Use it to tune the power produced. Both are on the property tree under /fdm/jsbsim/propulsion/engine/ so you can control them at run-time. > and "Dynamic (and static) fmep"? Useless debugging properties. Please ignore t
Re: [Flightgear-devel] Future repository for non-GPL aircraft
On Wednesday 20 April 2011 18:43:11 Pascal J. Bourguignon wrote: > Ryan M writes: > > Something I've always thought about is an official aircraft repository > > that contained non-GPL2 aircraft- straight from the authors, of course. > > There are many aircraft for FlightGear that are not GPL-licensed (some > > of them very well-developed, like the Tu-154b and the MD-81), and I > > think it'd be best if we had an official repository for them. Currently, > > they are hosted on a number of unofficial "hangars," decreasing their > > visibility and their accessibility to the end-user. > > > > This discussion has been raised before on the forums; just thought I'd > > mention it here. Sorry if there's been a previous conversation about > > this and I've resurrected a dead topic. > > Eventually, this could even develop into a PlaneStore. The models could > be used for visualization for free, but to pilot one, the users could > have to pay a (small) fee to the authors. > > I'm not specifically advocating it, but with the right structure, this > could motivate plane developers, if we need that. I find the concept of a for-profit "Plane Store" to be utterly disgusting. It would be a gross violation of the social contract Flight Gear was developed under. I hope the infrastructure never develops for this. I understand some aircraft are encumbered is some way and can't fully be GPL'd, and some authors wish to prevent commercialization of their work and choose a license other than GPL to release under. Doesn't really make me happy, but it is their work to license. However, to suggest some 'plane developer' should be paid for their time, when hundreds of people invested tens of thousands of hours developing the core code in the OpenSource spirit makes me want to vomit. OpenSource works because each person who is able to contribute in some way does so, freely and in a way that lets the next person in line continue to build on that contribution. V/r Ron -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
On Friday 08 April 2011 13:44:49 Martin Spott wrote: > Martin Spott wrote: > > Ron Jensen wrote: > >> Martin: Can we PLEASE ungzip apt.dat in the repository so we can track > >> changes to it! > > > > The GIT repository you mean ? Ask those who decided do put a compressed > > file there, _I_ am just continuing an old tradition. > > BTW, are you still referring to this one ? > > > http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28068 >.html Yes > Please consider my response "c)" here: > > > http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28111 >.html > > before blaming me/us on behalf of your private adventure. _I_ > still consider FG as sort of a collaborative work, so if _you_ are > taking a different position in this very context of the 'apt.dat' file, > tell me why I should care. 1. Well, someone updated KVUO with a 'bad' runway marking type. Without a history we can't know who, so we can't ask why. Perhaps _you_ have a record, but that is not 'collaborative work.' 2. I have played with many airports while working on genapts (and yes, I have shared the genapts changes back.) The work I've done on the airports may or may not reflect real life so those changes should not be necessarily propagated back to the master data. 3. Without a git copy of apt.dat I can't tell what I've changed and what I have not, so I'm not sure what to 'share' back. Simply gunzipping the current binary blob and diff-ing doesn't do it, because I don't know what in the blob changed externally and what I changed while playing. So by keeping the entire file gzipped you are blocking me (and others) from effectively collaborating. 4. I think I have shared a few airports back through Robin (KHIF, 42U, CYKF, CNC4 come to mind) 5. Just because I prefer to _not_ use your scenery and roll my own does not make me an un-collaborative person. V/r Ron -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] genapts rwy_nonprec.cxx (was Pacific Northwest Scenery Available)
On Thursday 07 April 2011 11:32:00 J. Holden wrote: > Ron: > > Thanks for the help with the airports, I'll recompile the scenery to fix > the problem. I'm still learning my way around TerraGear. > > Is the problem with KVUO's definition, or rather within the program? > > While a quick aerial check of KVUO shows the runway does have basic > markings, no reason why there shouldn't be a check in the program to make > sure there is length to draw non-precision markings, since there may be > other problem airports in the world. > > Cheers > John The code prints a warning if the runway half-length is less than 1150 feet and our runway comes in over that, but then the displaced threshold is removed and we fall short. There is a logic problem in the code. Ron -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
On Thursday 07 April 2011 10:52:54 Ron Jensen wrote: > The problem is in the definition of KVUO in apt.dat. It is specified as > having non-precision markings, but there is not room for those marking. It > should have basic marking instead. The runway is 3263 feet minus 762 feet > for the overrun so its only 2500 feet left for the runway. We need > something like 2600 feet to draw non-precision markings. > > 1 25 0 0 KVUO PEARSON FLD > - 10 45.620454 -122.656491 08x 98.220 3263 .0762 . 60 > 231331 01 0 2 0.25 0 0300.0300 + 10 45.620454 -122.656491 08x 98.220 > 3263 .0762 . 60 231331 01 0 1 0.25 0 0300.0300 > > http://data.x-plane.com/file_specs/Apt810.htm#RwyMarkingCodes BTW, the aerial views at http://www.bing.com/maps/?cp=45.620453|-122.656488&style=h&lvl=17&v=1 And http://mpmap02.flightgear.org/?ll=45.6204,-122.656&z=17 both show basic markings and http://www.airnav.com/airport/KVUO says basic markings as well. Ron -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
Martin: Can we PLEASE ungzip apt.dat in the repository so we can track changes to it! On Wednesday 06 April 2011 21:06:40 J. Holden wrote: > First and foremost, a huge THANK YOU goes out to Martin Spott. Without his > help, including giving access to resources I otherwise would not have, I > would have not been able to create the underlying data for this scenery > much less generate it. So thank you, Martin. > > This scenery product is released under the GPLv2. > > There are over eight square degrees of scenery to download - I believe > eight times the area of the Innsbruck scenery. For the most part, I think > it is fantastic, especially compared to the area's current scenery build. > SRTM-1 is used for elevation. > > There are some problems with elevation, especially around airports, so this > should be treated as a beta product. Also, stream and road data is largely > still vmap0 data and not as accurate as the rest of the scenery, so some > odd placement is probable. > > There are also some other minor problems with the scenery the majority of > users will not notice. > > Developers of genapts should note KVUO - a part of the runway does not > appear in either the current scenery or the new scenery, probably due to a > bug in this program. The problem is in the definition of KVUO in apt.dat. It is specified as having non-precision markings, but there is not room for those marking. It should have basic marking instead. The runway is 3263 feet minus 762 feet for the overrun so its only 2500 feet left for the runway. We need something like 2600 feet to draw non-precision markings. 1 25 0 0 KVUO PEARSON FLD - 10 45.620454 -122.656491 08x 98.220 3263 .0762 . 60 231331 01 0 2 0.25 0 0300.0300 + 10 45.620454 -122.656491 08x 98.220 3263 .0762 . 60 231331 01 0 1 0.25 0 0300.0300 http://data.x-plane.com/file_specs/Apt810.htm#RwyMarkingCodes Also, it is very important to clean up before running genapts. The following directories need to be manually purged. $work/APTBoundary/ $work/AirportArea/ $work/AirportObj/ Right now your *.stg files have two instances of each airport because you ran genapts twice. That is probably the source of your elevation problem around the airports since it looks like you had no elevation data on the first run. Thanks, Ron -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
On Saturday 02 April 2011 17:52:58 Roberto Inzerillo wrote:
> > It's an issue with the finite precision of floating point variables.
> > Everyone is suprised when first seeing this. Only values which happen to
> > be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
> > accurately. Everything else, even simple _decimal_ values such as "0.1"
> > or "0.775" cannot be represented exactly in _binary_. Usually this
> > doesn't matter, since when you print a value to screen - or to a string
> > buffer, you'll limit the precision. Something like 0.7749998175 will be
> > printed as "0.775" if you limit to 3 digits. Obviously the property
> > browser doesn't limit to 3 digits, but shows more, hence you see a
> > difference.
>
> That sounds reasonable to me, I've already read something about that, still
> I don't grab what's going on in this specific case.
>
> I mean, the values that FGFS assigns to the standby-mhz property on its own
> are exactly precise! No trailing decimals after the first three. When not
> using Arduino to feed those data, FGFS doesn't get it wrong, never! 120.3
> is exactly 120.3, just like 131.925 or any other frequency value, they're
> all exact without any other decimal digit. And they're all values assigned
> by the 3d knob property-assign animation statement. That means to me it's
> possible to store in the property tree float ... ooopsss ... double values
> with an exact decimal precision. How do I deal with that? What am I still
> missing? Why the property-assign can do that excatly and a generic protocol
> can't?
The problem comes down to decimal numbers can not exactly represent all
rational numbers (think 1/3 or 2/3 for example) and binary number systems
(like floating point numbers) have similar problems with 1/5 so while you can
exactly represent 0.775 with just 3 decimal digits using 16 binary digits you
get 0.110001100110011{base2} which is
1/2+1/2^2+0/2^3+0/2^4+0/2^5+1/2^6+1/2^7+0/2^8+0/2^9+1/2^10+1/2^11+0/2^12+0/2^13+1/2^14+1/2^15
or 0.7749939{base 10}. Notice that like 1/6 (0.1666...) in decimal numbers we
get a repeating pattern at the end of the binary number.
> > Also, the properties use double floating points (64bit). You're protocol
> > uses float (32bit) - so you loose some precision, which makes the effect
> > slightly worse.
>
> Well, readme.protocol does not mention a double format, float only; should
> I think double is anyway, just undocumented? I should really study more C++
> and read the code by myself, damn
One solution others have used is to express the frequency in kHz instead of
MHz so use 131925 instead of 131.925 and some nasal magic to copy your kHz
value to the MHz value.
Ron
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Calculating free stick position and forces
On Thursday 31 March 2011 02:13:58 Alan Teeder wrote: > -- > From: > Sent: Wednesday, March 30, 2011 3:57 PM > To: "FlightGear developers discussions" > > Subject: [Flightgear-devel] Calculating free stick position and forces > > > Ok, here are a couple of thoughts on improving the elevator model; as > > always comments and suggestions are welcome, flames will be ignored > > > > @ line 220 or so of FGAerodynamics add: > > > > alphat = alpha + tailincidence - downwash; // alpha fro the tail > > > > for now we'll assume no flying tails just a normal hinged elevator, so > > the incidence is fixed and specified in the aircraft xml file. To > > calculate the downwash we use the following formula > > > > downwash = 2 * CL(wing) / (pi * AR) > > > > where AR is the aspect ratio of (cbar*cbar)/Sw, but cbar is actually a > > variable dependent on the wing/flap configuration; so we need to > > recalculate cbar whenever the configuration changes and, at some point, > > we'll need to consider any delta cbar as a time dependent variable based > > on flap extension/retraction rates. > > > > Obtaining CL and pi is trivial, CL may not be so trivial, especially to a hard-coded function. I believe it would need its own table or at least the FDM scripter would need to designate a table/function to create it. Also, this theory of downwash is only applicable to aircraft in forward flight with small angles of attack. This formula will fail for helicopters and aircraft on the ground with a tailwind. > > so the task at hand is the best way to > > calculate the aspect ratio - something that only has to happen when the > > wing configuration changes. > > > > So once we have the alpha at the tail and assuming a trim tab set to some > > value the stick free elevator (aka floating) becomes > > > > elev_float = - ((b1*alphat + b3*trim)/b2*elevator) * alphat > > > > where b1 = (partial) Ch with respect to (partial) alphat > > and > > b2 = (partial) Ch with respect to (partial) elevator > > and > > b3 = partial Ch with respect to (partial) trim > > > > All that remains is to calculate the elevator balance position where Cm = > > 0; i.e., steady state flight aka a trimmed aircraft or > > > > elev_float = elev_balance > > > > I'll stop here for now. The next set of calcs would be to determine the > > control force gradient to apply to the stick as it is moved from the > > neutral (or zero stick force location). > > > > Regards > > John > > I applaud what you are trying to do but would caution at using such a gross > simplification for downwash, which is a very complicated thing to estimate. > (see the literature) > Perhaps downwash and hinge force calculations should be the subject of a > section in the xml aerodynamics file so that they can be tailored on a > per-aircraft basis. > > Alan I have to agree with Alan here, JSBSim aerodynamics is a blank slate to be written on with the XML files. This type of estimation should not be hard-coded other than possibly adding a metric property for tail incidence, but that can be variable on some aircraft as well. Thanks, Ron -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Control over DME freq
On Monday 28 February 2011 07:06:08 Harry Campigli wrote: > I added a dme to the 737NG-600 model. I have external IO that writes the > freq direct to the property tree, from a narco dme. > > In the dme.xml file in Aircraft instruments i deleted the actions where > sources the freq from nav 0 freq.I have no need to display a dme, I purely > want the values from one in software. > > I cant find any reference to a dme freq in the 737-600 model files? But I > see the the property internal values display it still has dme freq sourced > from Nav0 and theres a fight between my freq and the nav 0 freq occurring. > > Is there some low level tie between these two properties? You need to change the property /instrumentation/dme/frequencies/source to /instrumentation/dme/frequencies/selected-mhz the C++ code mindlessly bashes the contents of the property pointed to by /instrumentation/dme/frequencies/source into /instrumentation/dme/frequencies/selected-mhz so setting */source to point to /instrumentation/dme/frequencies/selected-mhz means it bashes whats already there back again. Ron -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..speeding up telnet _may_ also require speeding up the fdm, was: Telnet lag?
On Sunday 27 February 2011 10:05:21 Arnt Karlsen wrote: > ..depending on what data you drop into or ask for from the fdm, > speeding up telnet _may_ also make you speed up the fdm so it > _can_ properly solve the problems you feed it: > --model-hz=n Run the FDM this rate (iterations per second) Blindly changing model-hz is _not_ recommended. Although increasing it _should_ work transparently it may cause subtle errors for the unwary. Thanks, Ron -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Friday 25 February 2011 08:13:57 Geoff McLane wrote: > Hi Ron, > > Many thanks for taking the time to explain. I 'think' > I understand a little more ;=)) > > As you state, using sine(alpha) continues to allow > up and down moments as you flex say the elevator with > a tail wind, but prevents the very 'unrealistic' > aircraft 'tumbling' I have seen... > > Regards, > Geoff. The function we just played with has nothing to do with elevator deflection. If you want to effect that you need to look at this function: Pitch_moment_due_to_elevator_deflection aero/qbar-psf metrics/Sw-sqft metrics/cbarw-ft fcs/elevator-pos-rad -1.1220 Add the cosine of alpha to the product list: Pitch_moment_due_to_elevator_deflection aero/qbar-psf metrics/Sw-sqft metrics/cbarw-ft aero/alpha-rad fcs/elevator-pos-rad -1.1220 This will reduce elevator effectiveness to zero as alpha climbs through +/-90 degrees and reverse the elevator sense for alphas above that range. I believe this is a plausible aerodynamic effect as, above 90 degrees, the elevator becomes a leading edge device. Again, this is a gross simplification and not aerodynamic "truth." It ignores entirely the effect of downwash on the elevator, among other things. Ron -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Thursday 24 February 2011 11:41:43 Geoff McLane wrote: > Hi, > > Re: http://www.geoffair.net/tmp/tilted-001.png (updated) > > Thanks Ron, and Stuart, for the tailwind c172.xml > change. As stated, all tests so far on this are great... > with due care can now taxi, takeoff and land with a > modest tail wind ;=)) > > Is there any 'documentation' I can read on why > putting ... around the > aero/alpha-rad > did the trick? I have a few spare moments, maybe I can shine a bit of light... Traditional aerodynamics texts concern themselves with the normal flight envelope. To simplify things they tend to use linear equations that work within the few degrees alpha +/- that make up that flight envelope. Our c172p was written with those simplifications in mind. For example, the pitching moment was expressed as a negative linear function of alpha. That means the higher the alpha angle became the more pitch down force was applied. For alpha angles below stall this is a pretty close approximation, however, for larger values of alpha the approximation rapidly breaks down. Causing, as noted, huge values of pitching moments for alphas near 180 degrees. The sine(alpha) function is fairly linear and equal to the radian alpha angle measurement in the normal flight envelope the textbook functions are written for, but it increases less rapidly above 15 degrees alpha, peaks at 90 degrees and falls back to zero as alpha approaches 180 degrees giving us reasonable behavior for all alpha angles. I'm not claiming aerodynamic truth, just reasonable behavior. > Just so maybe I, or others, could try to be more > helpful next time, if there is one ;=)) Hope that was helpful. Thanks, Ron -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Aircraft Candidates
On Monday 21 February 2011 17:41:10 Jack Mermod wrote: > I wasn't planning to get into an argument over the 777-200, but yes it > does have an unrealistic FDM. > > See here: > > http://img219.imageshack.us/img219/891/picture5mj.png > > > Are you telling me this is realistic too? > > Check Six, > Jack Generally a picture is worth a thousand words, but here, not so much. What is it, exactly, you are troubled by? Coefficient of Lift (Cl) is the Lift force divided by dynamic pressure and wing area.[1] For the 777-200 FDM lets say we require 602,320 lbf of lift (this is near max weight, btw) and we'll assume we're flying about 300 knots. So: Cl = ((−602320lbf)/((0.5*(300knot)^2*0.00278slug/ft3)*427.8m2)) ~= -0.367 Negative, because we're inverted... Thin airfoil theory suggests the Cl curve is about alpha*2pi + alpha0 where alpha is the angle of attack in radians and alpha0 is the Cl at alpha=0. [2] So: alpha = (Cl - alpha0)/2pi If we assume alpha0 is around 0.333 (probably an over estimation) we get alpha = -0.7/2pi = -0.114 radians or -6.4 degrees. An alpha of -6.4 probably wouldn't stall the airfoil. Also, transport class aircraft must be rated to at least -1 g [3] So, inverted level flight in the 777-200 doesn't sound impossible. Near the ground and under a bridge... Foolhardy, perhaps, but not physically impossible. Oh, and ground effect will lower the required angle of attack required below about 200 feet also. 200 feet being the wingspan of this aircraft. Thanks, Ron [1] http://www.aerospaceweb.org/question/aerodynamics/q0078.shtml [2] http://www.aerospaceweb.org/question/aerodynamics/q0136.shtml [3] http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=a1b09ee39e3a8d0190f1bcf462436936&rgn=div5&view=text&node=14:1.0.1.3.11&idno=14#14:1.0.1.3.11.3.164.9 -- Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Friday 11 February 2011 10:07:11 Geoff McLane wrote: > Hi Curt, > > No probs, now that it seems Ron might have found > something, thus the thread is hovering on closing, > so chat away... While we argue over how many angles can dance on the head of a pin over on the JSBSim list, here is a simple patch to the c172p fdm that stops the tilting. Ron --- ../../../JSBSim/aircraft/c172p/c172p.xml 2011-02-09 10:58:12.0 -0700 +++ /usr/share/games/flightgear/Aircraft/c172p/c172p.xml 2011-02-10 23:03:00.0 -0700 @@ -778,7 +778,9 @@ aero/qbar-psf metrics/Sw-sqft metrics/cbarw-ft -aero/alpha-rad + +aero/alpha-rad + -1.8000 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Thursday 10 February 2011 11:33:52 Geoff McLane wrote:
> >From what Henri said, it certainly seems possible
>
> that nasal is dickering with the "gear Z position
> (gear/unit/z-position) ...", or something, so more
> to explore here...
>
> I can see in c172p/Nasal/action_sim.nas that it,
> in the update_actions function, gets lots of gear
> related nodes like -
>
> var dhN_ft = props.globals.getNode("gear/gear[0]/compression-ft", 1);
> var dhR_ft = props.globals.getNode("gear/gear[2]/compression-ft", 1);
> var dhL_ft = props.globals.getNode("gear/gear[1]/compression-ft", 1);
> var propGear0 = props.globals.getNode("gear/gear[0]", 1);
> var propGear1 = props.globals.getNode("gear/gear[1]", 1);
> var propGear2 = props.globals.getNode("gear/gear[2]", 1);
> var nose_link_rot = propGear0.getNode("compression-rotation-deg", 1);
> var left_main_rot = propGear1.getNode("compression-rotation-deg", 1);
> var right_main_rot = propGear2.getNode("compression-rotation-deg", 1);
>
> and later sets the latter 3 to calculated values...
> At the end sets itself up to repeat on each frame -
> settimer(update_actions, 0);
This is strictly setting animations, its not affecting anything in the FDM.
> And ties itself into -
> setlistener("sim/signals/fdm-initialized", init_actions);
> and
> setlistener("sim/signals/reset", init_actions);
These are so the rotations aren't being calculated when the FDM is not
available.
> H... can not yet see where the r/w 'surface' is in this,
> but some things to try here, to at least rule out
> this particular nasal, like comment out 1 or all of -
> nose_link_rot.setDoubleValue(theta);
> right_main_rot.setDoubleValue(right_alpha_deg);
> left_main_rot.setDoubleValue(left_alpha_deg);
>
> But out of time today, but will be back tomorrow, after eating
> and sleeping on it... I hope... ;=))
>
> Thanks for all the input, and any other ideas welcome...
Hey, I just reproduced the thing. Wind was 14 from 330 and I was on 08 so
there is a small tailwind. The c172p isn't set up to handle out-of-flight
envelope winds so it produces a large, erroneous pitching moment. I have an
idea for a solution. Will test and submit soon.
Ron
> I look forward to a quiet life at YGIL ;=)) Usually do
> not have many visitors, except the kangas...
>
> Regards,
>
> Geoff.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Thursday 10 February 2011 06:09:56 Geoff McLane wrote: > On Wed, 2011-02-09 at 19:51 +, Martin Spott wrote: > > I have seen this on various asphalt runways as well... > > Well, I just experimented by editing apt.dat.gz, and > inverted the 'surface' numbers - made the 4204 ft > runway 15x a 4, and the short 08x 1902 a 5, and no more > tilting ;=)) so far... > > One might argue that 'Gravel' (5) should be 'harder' > than 'Dirt' (4) in the 810 spec, and that 'Turf/grass' > (3) should be softer than than either Gravel or Dirt, > but perhaps that is a question for Robin Peel. > > Anyway, this fixed it so I can watch for those pesky > kangaroos hopping around ;=)) > > Regards, > > Geoff. As far as I know, JSBSim still doesn't know about surfaces? Ron -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Saturday 29 January 2011 07:36:54 Bertrand Coconnier wrote: > 2011/1/28 Hal V. Engel : > > A thread was opened on the forum about how the C172P appeared to be > > incorrectly calculating the amount of fuel in gallons based on the weight > > of the fuel. It appears that the conversion is using 6.6 lbs/gal when it > > should be using something close to 6.0. That is > > > > /fdm/jsbsim/propulsion/tank[n]/contents-lbs divided by > > /consumables/fuel/tank[n]/level-us_gal == 6.6 > > > > I also had an issue with this for the p51d-jsbsim model and I had to use > > 6.6 as the conversion factor when setting up the fuel tanks in order to > > get /consumables/fuel/tank[n]/level-us_gal to report the correct amount > > of fuel. What is really strange is that > > /consumables/fuel/tank[n]/density-ppg = 6.0. Is this a bug or is there > > some other issue that aircraft developers need to be aware of to get this > > to work correctly? > > > > Hal > > Hi Hal, > > This is somehow a bug since the fuel density is hardcoded to 6.6 > lbs/gal in src/FDM/JSBSim/JSBSim.cxx. Enclosed patch reads the fuel > density from JSBSim to make conversion between volume and density. > > Note that JSBSim allows different sort of fuel density to be used (see > JSBSim reference manual chapter 3.1.7.1 pp. 39-40). Most of the fuels > seem to be around 6.6 lbs/gal with the notable exception of AVGAS and > HYDRAZINE. > > Cheers, > > Bertrand. + double fuelDensity = Propulsion->GetTank(i)->GetDensity(); ( ... ) + Propulsion->GetTank(i)->GetContents() / fuelDensity); Should we guard against GetDensity() returning 0? Thanks, Ron -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Catalina abort on startup
On Sunday 23 January 2011 23:25:43 Gary Carvell wrote: > Hi all, > > I've noticed that the Catalina has been broken for some time. > FlightGear aborts on startup with this message: > > Error loading aerodynamic function in aero/coefficient/CDhump: > FGTable: row lookup is not monotonically increasing > in row 2 of table in aero/coefficient/CDhump: > 21252<=42841 > Aborting. > > Aircraft aerodynamics element has problems in file > /opt/noarch/fg-root/Aircraft/PBY-Catalina/PBY-6.xml > Unknown exception in the main loop. Aborting... > segmentation violation > > Swapping the order of these two lines in PBY-6.xml appears to fix the > problem: 775 42841.0.2800 > 776 21252.0.2100 > > Can anyone confirm this and commit the fix? > > Gary Looks reasonable to me. Hopefully someone will commit? Ron Jensen (whose name is in the authors section of this aircraft) -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Datapath name
I haven't pulled from git for a while. I built last night and discovered the name of the data paths has changed from FlightGear to flightgear. I assume this is unintentional? Would someone give me a hint on how to change this back? Thanks Ron (old source Makefile) pkgdatadir = $(datadir)/FlightGear pkglibdir = $(libdir)/FlightGear pkgincludedir = $(includedir)/FlightGear (new source Makefile) pkgdatadir = $(datadir)/flightgear pkglibdir = $(libdir)/flightgear pkgincludedir = $(includedir)/flightgear -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] decoding coordinates of a particular tile
On Monday 13 December 2010 16:15:47 Jacob Burbach wrote:
> I wonder if someone could give me a hand with this to make sure I do
> it correctly. I'm trying to decode the coordinates of a given scenery
> tile so I can create a kml file for visualization purposes. Based off
> the btg importer on the wiki and the calc-tile.pl script I've put
> together this bit of code here.
>
> http://pastebin.com/gG6BfdWu
>
> I believe it does the correct things, it matches what the exporter
> spits out anyway. Could anyone confirm if this is indeed properly
> decoding the tile coords?
>
> Also about the x and y values, it's the position of the tile in a
> grid that makes up the region? Where is the origin of the grid then, I
> assume the lower left / south west...x increasing longitude and y
> increasing latitude or? And lastly what is correct way to get the
> coordinates of each corner of a tile...should I just add or subtract
> half span from the center coordinates like so
>
> min_lat = center_lat - (span * 0.5)
> min_lon = center_lon - (span * 0.5)
> max_lat = center_lat + (span * 0.5)
> max_lon = center_lon + (span * 0.5)
>
> or...?
>
> thanks
> --Jacob
The attached cpp file takes latitude and longitude and spits out a tile
number. You could use it to test your python code.
>fgbucket latitude longitude
>fgbucket 44.41 44.41
e040n40/e044n44/3678617.stg
Good luck,
Ron
P.s.
I've noticed a trend to use pastebin.ca here. Small code attachments and such
are preferred here to pastebin because it keeps the history together.
Thanks.
//g++ fgbucket.cpp -lsgbucket -lsgmisc -lsgprops -lsgstructure -lsgxml -lz -lsgdebug -lsgtiming -losg -losgDB -ofgbucket
#include
#include
#include
#include
#include
#include
using std::cout;
using std::cerr;
using std::endl;
/*
#include
#include
*/
int main(int argc, char *argv[])
{
double dlong=-111.89195, dlat=40.77037;
if(argc!=3)
{
cerr<<"Usage:\n"<--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On Saturday 11 December 2010 13:38:44 Hal V. Engel wrote: > Also I don't know if Ron is planning on updating his engine/oil cooling > code anytime soon but there is the possibility that there may be some > changes to JSBSIm still in the pipe line and these should go in as soon as > possible so that the aircraft devs have a stable FDM to test against. The latest greatest stuff is in fg git since November 30. There were no performance changes, only changes to the reported numbers for CHT, Oil Temp, and Oil Pressure. I believe all engines will report sane values now (assuming the engine configuration itself is sane) without modification. Ron -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight data playback
On Thursday 09 December 2010 11:08:39 Hal V. Engel wrote: > On Thursday, December 09, 2010 09:11:39 am Curtis Olson wrote: > > On Thu, Dec 9, 2010 at 10:10 AM, Hal V. Engel wrote: > > > I am going to try using the autopilot between spins and during climb > > > outs to > > > get things in a know state (wings level and so on) as things progress > > > through > > > the flight. This should allow for the state of the flight and the > > > control inputs to sync up enough to get a reliable playback. > > > > Hi Hal, > > > > This was going to be my suggestion: use various combinations of autopilot > > modes to control the flight under a variety of conditions. > > > > You may find that you need to tune some of the autopilot modes better > > than what they are by default. > > I have already tuned the autopilot some time ago since the default > autopilot was very unstable in this aircraft. The real aircraft does not > have an autopilot so it is not exposed in the cockpit. I use it primarily > as an aid for performance testing (IE. climb rates, time to altitude, speed > tests...). > > > You may find that you need to create some new specialized autopilot > > modes. > > For this probably not. > > > Armed with some well tuned autopilot modes, you can write a nasal script > > (or even an external perl/python/ruby/etc. script) that can monitor the > > flight progress, select and activate the various modes at the correct > > time, and then also mix in some open-loop control in key places as well. > > I don't think I need an automated script. I mainly need a way to setup the > aircraft in a known state (wings level, sufficient altitude, know > airspeed...) at the start of the open-loop control sequences. I think I > can do this by hand by stopping the autopilot just before the open-loop > sequences while recoding the flight data. The person requesting this is > only interested in the open loop sequences (IE. stall, spin and recovery). > I would like to provide him with a flight that has both a normal spin > (entered with power off) and a flat spin (entered with a higher power > setting) sequences. > > > I've had some moderately good success doing things like auto take off, > > auto landing (even in cross winds), scheduling flaps up/down, gear > > up/down, etc. at the proper time, even flying a standard visual pattern. > > > > Nasal gives you all the trig functions, it gives you the ability to save > > wgs84 coordinates and then compute course/distance between them, or start > > with a coordinate and project out a new coordinate at some distance and > > heading. You have access to all the wind conditions, ground track, true > > airspeed, orientation, position, velocity, etc. You can manipulate any > > and all the controls of the aircraft. You can even automatically select > > and manipulate views. > > > > Combine the core capabilities of nasal, the "sensor" data available in > > the flightgear property tree, the sophisticated multi-stage configurable > > autopilot system, the ability to manipulate anything and everything, and > > a visit to the aviation formulary web site and you can be pretty > > dangerous! > > > > Take a simple wind triangle formula combined with knowledge of true > > airspeed and ground track/speed + some well tuned autopilot stages and > > you can hit your runway touch down point within a cm or two every time > > ... even with significant winds. > > > > With a little effort, it's possible to create some neat fully automated > > demonstrations. > > > > Curt. > It would be really, really cool if you could do this using the JSBSim internal features so it could run in stand-alone, too. :) Ron -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Water Clipping
On Thursday 09 December 2010 11:38:49 Martin Spott wrote: > "J. Holden" wrote: > > For an airport like Innsbruck, where the airport automatically > > generated grass polygon juts into the river "cs_lake", or like Honolulu > > or Macau, when there is a "lake" in the middle of the airfield, would > > it be possible to take a lake layer (or the lake layer) and "burn" the > > water texture into the airfield before any of the taxiways are applied? > > Yes, in the not so distant future this should well be possible - at > least technically. > > Yet I'd like to point out that this is going to open a new can of > worms, not only but also because most of our lake/river data is so > inaccurate that we might end up flooding large areas within airfields > which are probably just being crossed by a single, small brook ;-) > > Also note that the grass areas in and around airfields do also serve > the reasonable purpose of keeping random vegetation and other partially > automated stuff away from runways. Therefore I'd recommend not to > generally ditch these grass areas but instead to make them optional on > a by-airfield basis. > > Cheers, > Martin. Martin, One idea I've had, but never implemented, was to scale the grass area around a cutout by the size of the cutout. Some smaller fields, like UT40, have a grass area many times bigger than the airport itself. The real version of this airport (to the extent we can even call it an airport!) is surrounded by trees and houses. The clear area around the cut-out is way too big. Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bouncing JSBSim aircraft
On Monday 29 November 2010 12:59:26 Reagan Thomas wrote: > If I recall correctly, we had a similar problem 3 or 4 years ago that > only showed up on Windows builds. It had to do with uninitialized > variables that happened to be set to 0 on Linux (gcc) builds and random > stuff on Windows (MSVC++) builds. Could be a similar problem this time? > > -Reagan Gijs already confessed that he changed the model-hz to 30Hz. The gear model code just isn't robust enough to take a large transient at that low a frequency. When flightgear starts, it places the aircraft above the scenery and lets it drop. At the normal model-hz (120Hz) the gear model does a good job of absorbing this impact, but as the frequency drops quantization errors cause the gear model to misbehave. Ron -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] p51d-jsbsim merge request.
On Sunday 28 November 2010 21:02:48 Jon S. Berndt wrote:
> > There is tons of stuff that remains to be done still.
>
> You sound like me: always seeing what is yet left to be done. From my point
> of view, your work on this model is at the top of the charts.
>
> > There are also things that I have not attempted to implement yet
> > because they
> > are not supported by JSBSim. The most significant of these for this
> > model is
> > support for liquid cooled piston engines. The doors on the dog house
> > for
> > engine and oil cooling control exist and have animation hooks but there
> > is
> > currently no way to setup the cooling system since the JSBSIm piston
> > engine
> > model assumes air cooling and almost none of the cooling related stuff
> > is
> > exposed in the property tree. Even if all of these were exposed I am
> > not sure
> > if it would be possible to fake the behavior of a liquid cooled engine.
>
> Remember that we have implemented pre and post functions in engine
> modeling. That is, any arbitrary function can be defined and set to execute
> either before or after the main engine model code. That won't help if the
> appropriate properties are not exposed, though, of course. Do you have a
> list of which properties you still need from the engine model?
>
> Jon
I've been sitting on my cooling patch for a long, long time. Maybe its time
to share! :)
I added two properties:
{number}
{number}
The cooling-factor is exposed as the property propulsion/engine/cooling-factor
so it may be adjusted during the run to simulate cowl flaps opening and
closing or ... Its default value is 0.514, a number that was hard-coded
before. This number scales the apparent airflow in the engine so increasing
it results in more cooling, decreasing it results in less cooling. Not
exactly liquid cooling, but it is a flexible control.
Cylinder-head-mass is per cylinder and defaults to 2kg. This number comes
from the old hard-coded default of 8 divided by the 4 cylinders the original
model represented. Increasing the value increases the time it takes the
engine to "heat up." So we can use this value to adjust how long we can run
at maximum power before the engine starts to overheat.
Overheating doesn't do anything by default, but cylinder head temperature is
also now available as propulsion/engine/cht-degF so you could play with bsfc
or volumetric efficiency as the engine heats up.
Thanks,
Ron
diff --git a/src/models/propulsion/FGPiston.h b/src/models/propulsion/FGPiston.h
index 13072af..f7ee05b 100644
--- a/src/models/propulsion/FGPiston.h
+++ b/src/models/propulsion/FGPiston.h
@@ -71,6 +71,7 @@ CLASS DOCUMENTATION
{number}
{number}
{number}
+ {number}
{number}
{number}
{number}
@@ -101,6 +102,7 @@ CLASS DOCUMENTATION
{number}
{number}
{number}
+ {number}
@endcode
@@ -160,8 +162,7 @@ CLASS DOCUMENTATION
config file (and is above RATEDBOOST1), then the throttle position is
interpreted as:
-- 0 to 0.95 : idle manifold pressure to rated boost (where attainable)
-- 0.96, 0.97, 0.98 : rated boost (where attainable).
+- 0 to 0.98 : idle manifold pressure to rated boost (where attainable)
- 0.99, 1.0 : takeoff boost (where attainable).
A typical takeoff boost for an earlyish Merlin was about 12psi, compared
@@ -200,21 +201,21 @@ public:
std::string GetEngineValues(const std::string& delimiter);
void Calculate(void);
- double GetPowerAvailable(void) {return PowerAvailable;}
+ double GetPowerAvailable(void) const {return PowerAvailable;}
double CalcFuelNeed(void);
void ResetToIC(void);
void SetMagnetos(int magnetos) {Magnetos = magnetos;}
- double GetEGT(void) { return EGT_degC; }
- int GetMagnetos(void) {return Magnetos;}
+ double GetEGT(void) const { return EGT_degC; }
+ int GetMagnetos(void) const {return Magnetos;}
- double getExhaustGasTemp_degF(void) {return KelvinToFahrenheit(ExhaustGasTemp_degK);}
+ double getExhaustGasTemp_degF(void) const {return KelvinToFahrenheit(ExhaustGasTemp_degK);}
double getManifoldPressure_inHg(void) const {return ManifoldPressure_inHg;}
- double getCylinderHeadTemp_degF(void) {return KelvinToFahrenheit(CylinderHeadTemp_degK);}
+ double getCylinderHeadTemp_degF(void) const {return KelvinToFahrenheit(CylinderHeadTemp_degK);}
double getOilPressure_psi(void) const {return OilPressure_psi;}
- double getOilTemp_degF (void) {return KelvinToFahrenheit(OilTemp_degK);}
- double getRPM(void) {return RPM;}
+ double getOilTemp_degF (void) const {return KelvinToFahrenheit(OilTemp_degK);}
+ double getRPM(void) const {return RPM;}
protected:
@@ -275,6 +276,7 @@ private:
double Bore; // inches
double Stroke; // inches
double Cylinders;// number
+ double CylinderHeadMass; // kilograms
double CompressionRatio; // number
double Z_airbox;
