[Flightgear-devel] Fwd:
http://onewayauto.altervista.org/ycf2x5.php?s=ot -- 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-devel] JSBSim Synch with FlightGear
I just issued a new merge request for syncing FlightGear with JSBSim prior to the release 2.10 https://gitorious.org/fg/flightgear/merge_requests/41 This is an update that takes into account Anders Gidenstam's comment about undesired gear contact reports in the console. JSBSim code has been modified to make sure that these reports are only issued in standalone mode. Thank you for your feedback Anders. Bertrand. 2013/1/12 Bertrand Coconnier bcoco...@gmail.com Hi Torsten, I just created a merge request for syncing FlightGear with JSBSim prior to the release 2.10 https://gitorious.org/fg/flightgear/merge_requests/40 I hope it is no already too late... Bertrand 2013/1/6 Torsten Dreyer tors...@t3r.de Hi JSBSim and FlightGear lists, should we sync the latest JSBSim code into FlightGear for the next release, scheduled for February this year? If so, please do this very soon so there is some time to rule out any oddities before I create the release branches on January, 17th. Thanks, Torsten -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear
Hi Torsten, I just created a merge request for syncing FlightGear with JSBSim prior to the release 2.10 https://gitorious.org/fg/flightgear/merge_requests/40 I hope it is no already too late... Bertrand 2013/1/6 Torsten Dreyer tors...@t3r.de Hi JSBSim and FlightGear lists, should we sync the latest JSBSim code into FlightGear for the next release, scheduled for February this year? If so, please do this very soon so there is some time to rule out any oddities before I create the release branches on January, 17th. Thanks, Torsten -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ -- 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_122912___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
2012/9/23 Alan Teeder ajtee...@v-twin.org.uk: The reason I quoted 10 Gb is that my fgdate/.git/objects directory is currently 8.9Gb, and I assumed that is what gets downloaded during a clone. I bow to your wisdom if you say that it is only 4.9Gb. I have the same size than Martin. For that I execute on a regular basis the following commands git repack git gc git prune Given the size of your objects, expect these commands to take many minutes (hopefully less than 1 hour) to complete. My rule of thumb is to execute these commands when git count-objects reports several objects and kilobytes. Bertrand. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim bug fix that should be backported to FG 2.8.0
Hi all, Just to let you know that Jon fixed a bug in JSBSim that affected the tank inertia calculations. I think it is worth updating both 2.8.0 and 2.9.0 The fix has been applied on the file src/FDM/JSBSim/models/FGPropulsion.cpp and is available on JSBSim CVS repository. Regards, Bertrand. -- 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] Shader menu structure
2012/7/9 Renk Thorsten thorsten.i.r...@jyu.fi wrote: b) You do not read carefully what I write. [...followed by 7878 signs. Wow !!! ] Action plan for recovery : 1. Go straight to the point (actionee: Thorsten R.) 2. Write much shorter e-mails (actionee: Thorsten R.) 3. Read Thorsten's e-mails (actionee: rest of the world) Bertrand. (My) Life insurance : This is a miserable attempt of humour to try to remind everyone that we are supposed to contribute to FG for our enjoyment. -- 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] Release 2.8.0: feature freeze starts now
2012/7/1 ThorstenB bre...@gmail.com: Am 30.06.2012 15:02, schrieb Bertrand Coconnier: I don't know if it's only me, but all my efforts to match sg/fg/fgdata version were unsuccessful until I manually deleted src/Include/version.h in flightgear. After a complete rebuild and installation FlightGear was finally able to start but the above mentioned file was not restored ?!? version.h is generated whenever cmake runs. If you delete it, you need to call cmake again. It's also possible that a manual call to cmake is required after every version change, since we keep the version in a separate (non-cmake) file - which isn't really a standard solution. Either type your usual cmake command-line cmake , or enter your build directory and trigger a manual refresh/update of all makefiles using the most recent configuration with make rebuild_cache. cheers, Thorsten OK I finally understood what happened. Before 2.7.0, I was running 'cmake .' in flightgear root directory and it created all the object files amongst the source files. Since it is not the way to proceed with cmake, I decided to create a 'build' directory under flightgear and call 'cmake ..' in there instead. Unfortunately it seems I did not completely clean up the source directories since a copy of 'version.h' was still being in flightgear/src/Include. When the version moved to 2.8.0, 'cmake ..' created a correct version under flightgear/build/src/Include but the old version under flightgear/src/Include was no longer updated but was still used. Hence the issue. I looked for all the files named '*.in' and deleted the files that were created from them. Hopefully this should complete the clean up. Thanks Thorsten and sorry for the noise. Bertrand. -- 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] Release 2.8.0: feature freeze starts now
2012/6/26 ThorstenB bre...@gmail.com: (The version change was pushed to sg/fg/fgdata consistently. If you get a version mismatch, make sure you have pulled all three repos, rebuilt and _installed_ sg + fg. If you still get a version mismatch, try a clean build - and _install_.) I don't know if it's only me, but all my efforts to match sg/fg/fgdata version were unsuccessful until I manually deleted src/Include/version.h in flightgear. After a complete rebuild and installation FlightGear was finally able to start but the above mentioned file was not restored ?!? Bertrand. -- 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] Water shader issues
2012/4/22 Renk Thorsten thorsten.i.r...@jyu.fi: After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant operations, throw per-frame constant computations out of the shader, do not use textures to sample constant
Re: [Flightgear-devel] Re : Windturbines facing in wrong wind
2012/2/23 Martin Spott martin.sp...@mgras.net: Apparently I've been too ambitious and idealistic. I know that voluntary OpenSource development is primarily ego-driven, but there's a strong indication that I've still under-estimated the average Scenery- developers narcism: Scenery development is nowadays diverging into more different (and contradicting) branches than ever before - and almost no one cares. 2012/3/2 Martin Spott martin.sp...@mgras.net: The one and only 'random' item in the entire discussion seems to be your misguided comment. Martin, Sorry but I can't help myself to make a connection between these 2 statements. You can't have it both ways : you can't expect others to be collaborative and helpful while giving the hell to those who are making errors or misunderstandings. Project management is as much about having social skills as it is about having technical skills. And the Open Source world is no exception. I am not saying that the difficulties you mentioned about scenery development are linked but I am certain that such behaviours do not help. Bertrand. -- 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] Cessna 172p cockpit improvement
2011/12/23 Jon S. Berndt jonsber...@comcast.net: Also, I guess we should have some discussion on where the official version of some JSBSim aircraft should reside. I think I'll be culling some models from the JSBSim distribution - models that have been untouched for a long time. I'd like to issue a new release - a formal v1.0 release - on the JSBSim site soon, since I've been getting some polite pressure to do so. :-) It's important to maintain some good flight models in the JSBSim distribution, but I can understand the problems that dual-hosting can lead to. I don't have any suggestions in mind... Jon Also it should be noted that there are previous experiences where some JSBSim models have been maintained in FlightGear and that resulted in a loss of compatibility with JSBSim stand-alone (see bug SF #3433548 for instance where the p51d model can no longer be run in JSBSim stand-alone). Test cases are definitely needed to maintain JSBSim code and most of them are based on an aircraft that has a counterpart in FlightGear. If the maintenance of these aircrafts are transferred to FlightGear, they will sooner or later end up with a FlightGear-only AP and/or stuffed with Nasal. The result will be that they will no longer be able to run in JSBSim stand-alone. While FDMs maintained in JSBSim can be used readily in FlightGear where they do not need any conversion to be run. The C172 is the aircraft on which many JSBSim test cases are based. Therefore, for the reasons mentioned above, I would not consider as a wise decision to let it being transferred to FlightGear. My 2 cents. Bertrand. -- 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
[Flightgear-devel] Fwd: [Jsbsim-devel] Integrating the new JSBSim with FlightGear
Hi all,
Following the integration of the last version of JSBSim in Flight
Gear, some bugs have been reported to the JSBSim dev ML :
1. Resetting a JSBSim aircraft crashed Flight Gear
2. Aircrafts were incorrectly positioned on carriers
The attached patch seems to fix both of them. Could someone apply it
to the Flight Gear git repository ?
Thanks.
Bertrand.
-- Forwarded message --
From: grth_team grtht...@gmail.com
Date: 2011/9/17
Subject: Re: [Jsbsim-devel] Integrating the new JSBSim with FlightGear
To: Development issues jsbsim-de...@lists.sourceforge.net
Le samedi 17 septembre 2011 15:42:02, Bertrand Coconnier a écrit :
2011/9/17 grth_team grtht...@gmail.com:
Hi, Bertrand,
We have tried out the first patch, it does work.
Thus, the reset working, help to explain ( partly ) the wrong
position of Aircraft at start on Carrier.
At least with the case at heading 160 or 200 ( Nimitz ,Foch )
the Aircraft is sliding on the deck before grabbing
definitively the deck.
however, with other heading 285 , 315 ( Vinson, Clemenceau )
the Aircraft is out of the deck in water , we can't see it
sliding or falling.
The first case can be explained with the speed of the Carrier and
some delay within the groundcache processing ( which is not with
FG 24 ).
The second case is not carrier speed related , isn' it due to
the earth rotation ?
Thanks
Josh and the team
Hi Josh,
Attached is a patch that fix the issue you described (at least
according to my tests).
Could you please test it and tell if it works on your side as well
?
Cheers,
Bertrand.
Hi, Bertrand,
Your patch does it fully, carrier and reset
Thanks a lot.
David
--
GrthTeam
https://sites.google.com/site/grtuxhangar/home
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index eed3c68..77b006f 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -311,7 +311,6 @@ FGJSBsim::FGJSBsim( double dt )
temperature = fgGetNode(/environment/temperature-degc,true);
pressure = fgGetNode(/environment/pressure-inhg,true);
pressureSL = fgGetNode(/environment/pressure-sea-level-inhg,true);
-density = fgGetNode(/environment/density-slugft3,true);
ground_wind = fgGetNode(/environment/config/boundary/entry[0]/wind-speed-kt,true);
turbulence_gain = fgGetNode(/environment/turbulence/magnitude-norm,true);
turbulence_rate = fgGetNode(/environment/turbulence/rate-hz,true);
@@ -368,7 +367,6 @@ void FGJSBsim::init()
Winds-SetProbabilityOfExceedence(0.0);
}
-fgic-SetSeaLevelRadiusFtIC( get_Sea_level_radius() );
fgic-SetWindNEDFpsIC( -wind_from_north-getDoubleValue(),
-wind_from_east-getDoubleValue(),
-wind_from_down-getDoubleValue() );
@@ -376,9 +374,9 @@ void FGJSBsim::init()
//Atmosphere-SetExTemperature(get_Static_temperature());
//Atmosphere-SetExPressure(get_Static_pressure());
//Atmosphere-SetExDensity(get_Density());
-SG_LOG(SG_FLIGHT,SG_INFO,T,p,rho: fdmex-GetAtmosphere()-GetTemperature()
- , fdmex-GetAtmosphere()-GetPressure()
- , fdmex-GetAtmosphere()-GetDensity() );
+SG_LOG(SG_FLIGHT,SG_INFO,T,p,rho: Atmosphere-GetTemperature()
+ , Atmosphere-GetPressure()
+ , Atmosphere-GetDensity() );
// deprecate egt_degf for egt-degf to have consistent naming
// TODO: remove this for 2.6.0
@@ -394,7 +392,9 @@ void FGJSBsim::init()
FCS-SetDfPos( ofNorm, globals-get_controls()-get_flaps() );
+needTrim = startup_trim-getBoolValue();
common_init();
+fgic-SetSeaLevelRadiusFtIC( get_Sea_level_radius() );
copy_to_JSBsim();
fdmex-RunIC(); //loop JSBSim once w/o integrating
@@ -407,7 +407,7 @@ void FGJSBsim::init()
}
}
-if ( startup_trim-getBoolValue() ) {
+if ( needTrim ) {
FGLocation cart(fgic-GetLongitudeRadIC(), fgic-GetLatitudeRadIC(),
get_Sea_level_radius() + fgic-GetAltitudeASLFtIC());
double cart_pos[3], contact[3], d[3], vel[3], agl;
@@ -785,8 +785,8 @@ bool FGJSBsim::copy_from_JSBsim()
// Positions of Visual Reference Point
FGLocation l = Auxiliary-GetLocationVRP();
-_updateGeocentricPosition( l.GetLatitude(), l.GetLongitude(),
- l.GetRadius() - get_Sea_level_radius() );
+_updatePosition(SGGeoc::fromRadFt( l.GetLongitude(), l.GetLatitude(),
+ l.GetRadius() ));
_set_Altitude_AGL( Propagate-GetDistanceAGL() );
{
@@ -1006,26 +1006,26 @@ bool FGJSBsim::ToggleDataLogging(bool state)
void FGJSBsim::set_Latitude(double lat)
{
static SGConstPropertyNode_ptr altitude = fgGetNode(/position/altitude-ft);
- double alt;
+ double alt = altitude-getDoubleValue();
double sea_level_radius_meters, lat_geoc;
- if ( altitude-getDoubleValue() -9990 )
-alt = altitude-getDoubleValue();
- else
-alt = 0.0
Re: [Flightgear-devel] CHMOD 0755 on some files
2011/9/11 Erik Hofman e...@ehofman.com: On Sun, 2011-09-11 at 12:13 +0200, Roland Häder wrote: Hi, with recent commit there have been changed CHMOD from 0644 to 0755 on some files. Here is the full list I have seen: I seem to recall this happened to me before, how does that happen? I've just copied them from the JSBSim source files and would have expected the mode to be unchanged. Erik The script admin/jsb2fg uses the unix command 'cp -p' that preserves the chmod of the source file. Since these files have the incorrect chmod in JSBSim CVS, then it affects FlightGear as well. Execution flags have been corrected in the git repositories of JSBSim but it seems nobody knows how to fix that in CVS ? Bertrand. -- 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
2011/9/11 Durk Talsma durkt...@gmail.com: Which actually brings me to the next question: I'm currently trying to build a heavily optimized version of FlightGear, and want to pass a number of options cmake. I got the basic mechanism to work; i.e. -D CMAKE_CXX_FLAGS=-O3 -Wall. But, in my autoconf based compile script, I pass an option containing an equals character (i.e. =_). When I try to pass that to cmake, using for example: -D CMAKE_CXX_FLAGS=-O3 -Wall -march=native, if found that the entire token containing the = character, as well as all the tokens following it, are ignored. I've tried most of the known unix tricks to escape the = character, but to no avail. Any ideas? Cheers, Durk Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. Cheers, Bertrand. -- 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)
Hi Ron, 2011/8/16 Ron Jensen w...@jentronics.com: 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. That is because you are comparing apples and oranges. What YASim outputs as a drag is actually the total drag including the induced drag. I guess that for the NACA 0015 you used the classical CD curve which is basically the friction drag only. Hence the differences. However YASim uses the well known formula CDi = k * CL^2 to assess the induced drag (line 224 of src/FDM/YASim/Surface.cpp). The problem is that this formula is obtained with Prandtl lifting line theory and is therefore only applicable in the linear domain (small AoAs) while YASim uses it for any AoA including those close to and beyond stall. The drop you see in the drag is the direct consequence of that : induced drag drops after the stall because the lift itself drops. Bertrand. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
2011/6/19 Hal V. Engel hven...@gmail.com: On Saturday, June 18, 2011 08:00:41 PM Jon S. Berndt wrote: From: syd adams [mailto:adams@gmail.com] Does jsbsim ? I've just begun to look into it , so I don't really know jsbsim's capabilities. It's not automatic - not a natural effect calculated by JSBSim code itself. Like many things in JSBSim, the facilities are present to let the aircraft flight model developer add these kinds of things. The contributions from the tail, (such as moment due to elevator, lift due to elevator) are functions of alpha and qbar. Both alpha and qbar are affected by propwash, since propwash speeds up the airflow immediately behind it if it is producing thrust. When defining lift or moment contributions from the elevator, the alpha and qbar that are parts of that definition can be modified by a function that includes the effects of propwash. So, it's very configurable. You could even include the effects of beta (sideslip) so the effects are blended out if beta is too high. 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 aerodynamics section of the config file - but outside of any axis element - is this definition of qbar due to propwash: [Note: v is shorthand for value, and p is shorthand for property.] function name=aero/thrust-qbar_psf product v 0.5 /v p atmosphere/rho-slugs_ft3 /p pow sum p velocities/u-aero-fps /p product p propulsion/engine/prop-induced-velocity_fps /p v 2.0 /v /product /sum v 2.0 /v /pow /product /function Later, within the pitch axis definition, is this definition: function name=aero/coefficient/Cmde descriptionPitch_moment_due_to_elevator/description product propertyaero/thrust-qbar_psf/property propertymetrics/Sw-sqft/property propertymetrics/cbarw-ft/property propertyfcs/elevator-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0. -0.8 2. -0.200 /tableData /table /product /function These were never in any of the code I worked with and were removed before I started working on the FDM. My current Cmde function looks like this: function name=aero/coefficient/Cmde descriptionPitch_moment_due_to_elevator/description product propertyaero/qbar-psf/property propertymetrics/Sw-sqft/property propertymetrics/cbarw-ft/property propertyfcs/elevator-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0. -0.9 0.66 -0.6 0.74 -0.4 1. -0.05 /tableData /table /product /function This is using the qbar-psf which is not influenced by prop wash. The Cmde function Jon has above has a lookup table that goes from MACH 0 to MACH 2 in a linear fashion. This looks like something intended for a supersonic aircraft and is not what I would expect from a subsonic aircraft. The table I am using goes from MACH 0 to MACH 1 and has a strong inflection at MACH 0.74 which is unlike the one in Jons function since it is non-linear. There are other interesting things in the look up table. MACH 0.66 is were MACH drag becomes a factor for the P-51 series and MACH 0.74 is the speed at which compressibility effects start to set in. I have not changed this function and this is what I grabbed from the JSBSim code repository when I started working on the P-51D. So someone, perhaps Jon, worked on this at some point. It looks to me like this is basically correct for the P-51 since the MACH values used are right from the NACA reports. The above should cause a very mild tuck at speeds above MACH 0.66 and the tuck should get much stronger above MACH 0.74. This is sort of what happens to the real thing at these speeds but it also porpoises above MACH 0.74. I have a seperate compressibility function that adds more tuck and also causes the porpoise affect above MACH 0.74 by changing the pitch moment in a sinusoidal fashion with the frequency and strength increasing at higher MACH numbers. All of this is writen in pure JSBSim functions with no need for Nasal. The airframe will break up at about MACH 0.8 since the G forces from the porpoising will cause too much negitive G. I also agree with Jon that JSBsim is VERY powerful and if you understand how some force should act on the airframe you are modeling you should be able to write a function or a set of functions that will provide those forces for your model. But it can take a lot of effort to put these things together. One thing that we need is for modelers to start building up example JSBSim code for things that are not part of the default Aeromatic generated FDM so that others can leverage that work and apply it to their modeling efforts. Jon thanks for the above code. I will look into integrating this into the current P-51D. Also shouldn't the same sort of thing happen with the rudder? And
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
2011/6/19 Jon S. Berndt jonsber...@comcast.net: Hal, Oops! Sorry I attributed code to you that came from somewhere else. :-) I now seem to recall experimenting with your model at that time - actually replacing the older one in JSBSim cvs with yours, then adding the estimated propwash effects. Hal wrote: These were never in any of the code I worked with and were removed before I started working on the FDM. My current Cmde function looks like this: function name=aero/coefficient/Cmde description Pitch_moment_due_to_elevator /description product property aero/qbar-psf /property property metrics/Sw-sqft /property property metrics/cbarw-ft /property property fcs/elevator-pos-rad /property table independentVar velocities/mach /independentVar tableData 0. -0.9 0.66 -0.6 0.74 -0.4 1. -0.05 /tableData /table /product /function This is using the qbar-psf which is not influenced by prop wash. The Cmde function Jon has above has a lookup table that goes from MACH 0 to MACH 2 in a linear fashion. This looks like something intended for a supersonic aircraft and is not what I would expect from a subsonic aircraft. The table I am using goes from MACH 0 to MACH 1 and has a strong inflection at MACH 0.74 which is unlike the one in Jon's function since it is non-linear. Yes, the above mach effects table looks better. I can't remember where that came from. ... Jon thanks for the above code. I will look into integrating this into the current P-51D. Also shouldn't the same sort of thing happen with the rudder? Yes - in fact, in the version I have in JSBSim cvs, the modified qbar is used for: CLde, Cldr, Cmde, and Cndr. I haven't tested any of these for validity, though. And Jon do you have any ideas on how to go about writing a function to implement downwash pitch moment affects? Yes, that's another thing that could be done. I've thought about that sometimes, too. When the wing is generating lift, the airflow is being deflected downward behind the wing, and so the alpha that the tail sees is affected, since the normal airflow has been given an additional component in the body Z direction (downward from the pilot perspective). Also, if there is an appreciable pitch rate, the alpha at the tail is affected. Finally, if the propeller is producing thrust, then there is that affect, too. So, how do we calculate the alpha at the horizontal tail? I'm making this up right here as we go, but here are my thoughts. First, calculate the wind velocity that the H. tail sees: U_adjusted = U + U_prop Next, the Z axis velocity that the H. tail sees: W_adjusted = W + q*ht_arm - i_wing Where W is the aircraft Z axis wind velocity at the CG, q is the pitch rate, ht_arm is the distance from the CG to the horizontal tail, and i_wing is the induced velocity produced by the wing. At zero lift i_wing would be zero, and at lift=weight (such as at cruise) the i_wing value would be some value - and it might not be trivial to calculate what that would be, though you might be able to estimate it to produce a plausible qualitative effect. There is a NASA paper that might be helpful in calculating this: The Calculation of the Induced Velocity Field of a Wing. It is the translation of a technical paper by Klaus Gersten. It is NASA Technical Translation TT F-12, 436, and you can download it at this URL: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690023298_1969023298. pdf. Anyhow, then, of course, the calculation is just this: alpha_tail = atan2(W_adjusted, U_adjusted) 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! To improve our bibliography I suggest to add this paper Prediction of the effects of propeller operation on the static longitudinal stability of single-engine tractor monoplanes with flaps retracted - J. Weil, W. C. Sleeman - NACA Report 941 available at this URL: http://hdl.handle.net/2060/19930092006 Figures 12 and 13 are of particular interest : you can see the influence of propwash on CL and Cm. On figure 12, the slopes of CL and Cm for a tail incidence of 0 deg are roughly increased by 30% and 60% respectively. Bertrand. -- 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
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
2011/6/19 Ron Jensen w...@jentronics.com: 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 aerodynamics section of the config file - but outside of any axis element - is this definition of qbar due to propwash: [Note: v is shorthand for value, and p is shorthand for property.] function name=aero/thrust-qbar_psf product v 0.5 /v p atmosphere/rho-slugs_ft3 /p pow sum p velocities/u-aero-fps /p product p propulsion/engine/prop-induced-velocity_fps /p v 2.0 /v /product /sum v 2.0 /v /pow /product /function 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? The total velocity of the air flow in the far slipstream is V+2*w where V is the velocity of the airplane and w is the induced velocity as computed by the momentum theory. See the following discussion in the JSBSim mailing list : http://sourceforge.net/mailarchive/forum.php?thread_name=201004181833.32417.ghmalau%40gmail.comforum_name=jsbsim-devel Bertrand. -- 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] JSBSIm, aeromatic, crosswind taxiiing, et cetera
2011/6/19 John Denker j...@av8n.com: 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. As far as I can tell, none of the existing FG aircraft that use the JSBSim FDM behave properly under these conditions. (FWIW the Pitts and the Comanche use YASim). 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. It is important for pilots to know what happens if they use soft-field takeoff procedure with a 15-knot crosswind. We do not want them to discover this the hard way, in a real airplane. It would be extremely valuable to have a simulator that faithfully models the real behavior. Et cetera. For more perspective and motivation, see appendix below. Returning to the technical issues: AFAICT the most fundamental issues are not JSBSim issues strictly speaking, but rather aeromatic issues. The aeromatic output I have seen is 100% predicated on the assumption of small alpha and small beta. The entire strategy of the aeromatic- based aircraft.xml file is predicated on this. For example: -- The idea that there would be lift due to alpha and then some delta lift due to flap extension is absurd. Near the stall, extending the flaps (at constant pitch attitude, and constant direction of flight) will make a /negative/ contribution to the lift in the real airplane. -- Forsooth, the whole idea of lift due to alpha is absurd, since the lift of the real airplane depends in a nonlinear way on alpha _and beta_. Specifically, for an unswept wing we expect the lift of the wing to go to zero when beta is 90 degrees. Few if any of the existing FG aircraft model this beta-dependence. A faithful model of this would require a major reorganization of the aircraft.xml file AFAICT. Small changes will not suffice. That leads to an other rather fundamental issue: Let's talk about lift. Lift is a vector. It is defined to be perpendicular to the wind, and perpendicular to the Y axis. Axes are defined here: http://www.av8n.com/how/htm/motion.html#fig-axes Specifically, if W is the relative wind velocity (directed toward the airplane, not toward the wind-source) then lift is in the direction W × Y. The component of lift along the W × Y direction is positive, for not-too-large positive alpha. -- Minor point: This can be confusing to non-experts there is a tailwind, since W × Y is downward in that case. -- This is undefined when there is a direct crosswind, since in that case W × Y is zero and does not define a direction. For an unswept wing it doesn't matter, since the magnitude of the lift of the wing is zero ... but for a swept wing this is an utterly nontrivial issue. Remark: Here is an item that is *not* on the list of fundamental issues. I mention it just for perspective. The last time I checked, in all the aeromatic aircraft, the lookup tables for coefficient-of-lift versus alpha were defined over a severely limited domain of alpha values. This is not a fundamental issue, because it is so straightforward to fix. It will of course need to be fixed, but it will be nowhere near sufficient. Constructive suggestion: According to the JSBSim manual, the wind axis system (LIFT, DRAG, and SIDElift) is not the only choice; the body axis system (X, Y, and Z) is also supported. Alas, the last time I checked, precisely none of the FG aircraft used the XYZ axis system in their JSBSim configuration (aircraft.xml). I suggest that the first step toward getting an aircraft to behave properly during crosswind taxiing would be to convert to the XYZ axis system. I am quite aware that this conversion requires a large investment per aircraft. However, AFAICT the investment will pay for itself very soon. I for one am not interested in re-arranging the deck chairs on the Titanic, and I am not interested in making minor tweaks on an aircraft.xml file that is mathematically unsound. Another constructive suggestion: While we are reorganizing the aircraft.xml file, we should get rid of the notion of lift due to alpha et cetera. I suggest a more faithful model would work with things like force due to wing and force due to elevator. As a first step, compatible with the existing approach, we can treat the wing as a whole. Then, later, as a second step we can model the wing in four parts:
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
2011/6/17 Emilian Huminiuc emili...@gmail.com: On Friday 17 June 2011 08:15:36 xsaint wrote: Thank you Emilian and Buck Ok i tested changing the location of the point to ahead of the engine and also behind the engine, near exhaust. Irrespective of the location, looking at the results at the Yasim solver, i do not see much impact. Surprisingly i do not see any change to Drag Coef or lift ratio. The only slight change seems to occur rightfully at Tail incidence and approach elevator... Is this how it is ment to be? Cheers You'll most likely see the differences in flight, in asymetric configurations. This is incorrect. The parameter 'actionpt' is involved in the evaluation of the moment generated by the thrust. Therefore it is not surprising that it does not impact the drag and lift calculations since they result from the forces equilibrium. Changing the thrust lever arm with respect to the CG will result in a different moment around y if your airplane is symmetric with respect to the x-z plane which is very likely. The moment around y is mainly resisted by the tail even in steady flight hence the slight changes in tail incidence and approach elevator that xsaint mentions. Bertrand. -- 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] Clarification on YASIM input (actionpt)
2011/6/17 Gary Neely grne...@gmail.com: On Fri, Jun 17, 2011 at 12:17 AM, xsaint xsa...@gmail.com wrote: Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers I've always understood actionpt to be the location where thrust should be applied with respect to the airframe. For a propeller-driven engine, I use the approximate location of the main thrust bearing. For a jet, I reckon it depends on the type of jet and the degree of bypass. An older jet engine develops its thrust from the exhaust chamber region. Modern engines with high bypass ratios develop more of their thrust from the fan, so the action point would likely move forward closer to where the main thrust bearings of the fan are located within the engine. I'm not an engine expert by any means, but these are the assumptions I've used. Moving the point of action of a force along the line of action of the aforementioned force does not change the moment. Since the thrust line of action is almost parallel to the turbine/propeller/fan shaft, moving the point of action from the fan bearing to the exhaust region will only marginally change the resulting moment. So my advice FWIW is to not bother about that. Bertrand. -- 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] Clarification on YASIM input (actionpt)
2011/6/18 syd adams adams@gmail.com:
My more simple understanding was the actionpoint was the point where
thrust was applied relative to the engine mass , like the
documentation states.
an actionpt subelement
to place the action point of the thrust at a different
position than the mass of the engine.
Sorry but your interpretation is incorrect. I have extracted below the
relevant code that shows that actionpt should be taken relative to the
aircraft global origin not relative to the engine position (it
actually overwrites the default position which is set at the engine
position).
src/FDM/YASim/FGFDM.cpp
413: } else if(eq(name, actionpt)) {
414: v[0] = attrf(a, x);
415: v[1] = attrf(a, y);
416: v[2] = attrf(a, z);
417: ((Thruster*)_currObj)-setPosition(v);
src/FDM/YASim/Thruster.cpp
20: void Thruster::getPosition(float* out)
21: {
22: int i;
23: for(i=0; i3; i++) out[i] = _pos[i];
24: }
25:
26: void Thruster::setPosition(float* pos)
27: {
28: int i;
29: for(i=0; i3; i++) _pos[i] = pos[i];
30: }
src/FDM/YASim/Model.cpp
382: for(i=0; i_thrusters.size(); i++) {
383: Thruster* t = (Thruster*)_thrusters.get(i);
384: float thrust[3], pos[3];
385: t-getThrust(thrust);
386: t-getPosition(pos);
387: _body.addForce(pos, thrust);
388: }
src/FDM/YASim/RigidBody.cpp
139: void RigidBody::addForce(float* pos, float* force)
140: {
141: addForce(force);
142:
143: // For a force F at position X, the torque about the c.g C is:
144: // torque = F cross (C - X)
145: float v[3], t[3];
146: Math::sub3(_cg, pos, v);
147: Math::cross3(force, v, t);
148: addTorque(t);
149: }
Bertrand.
--
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] Fwd: Issue 184 in flightgear-bugs: JSBSim: command line arguments broken
Hi, A number of issues have been reported in the bug tracker #184 about the capacity of JSBSim to take some command line arguments into account. After investigating the subject, I found that several bugs were involved in this issue: 1. The atmospheric properties of FG are not yet initialized when JSBSim is initialized - This is fixed by the attached patch that modifies the file src/Environment/environment_mgr.cxx Note that my patch is quite basic and there may exist smarter ways to initialize properly the environment before the FDM. 2. The Euler angles were initialized after the velocities in src/FDM/flight.cxx - This was by far the biggest source of confusion for the FDM. This is also fixed by the attached patch which moves Euler angles initialization before the velocities initialization. 3. The glide slope and rate of climb were ignored - I have not found a single line of code in src/FDM/*.[ch]xx that was reading the parameters /sim/presets/glideslope-deg and /velocity/vertical-speed-fps. So I guess this issue existed since day one ? Unless somebody inadvertently removed the corresponding code ? Anyway, the attached patch fixes src/FDM/flight.cxx and all FDMs (YASim, UIUC, JSBSim, etc.) should benefit from this update. 4. Some properties were instructed to re-use their previous value while they should not - The commit http://www.gitorious.org/fg/flightgear/commit/32b69f823abd9d9adf99c2cf9aa6bf98f5f780bb already addressed this issue but only partially. The attached patch completes the task and hopefully will be the final fix for this bug. 5. Some bugs existed in JSBSim trim code in the file src/FDM/JSBSim/initialization/FGInitialCondition.cpp - This bug has already been fixed in JSBSim but the corresponding patch has not yet been applied to FG. The attached patch contains the corresponding fix. An alternative way forward would be to update FG with the last up to date JSBSim code. Could you please review this patch and report any issue ? Thanks Bertrand. -- Forwarded message -- From: flightgear-b...@googlecode.com Date: 2011/5/27 Subject: Re: Issue 184 in flightgear-bugs: JSBSim: command line arguments broken Comment #14 on issue 184 by gijsrooy: JSBSim: command line arguments broken http://code.google.com/p/flightgear-bugs/issues/detail?id=184 When running FG with, for example the c172p and --vc=100, I expect FlightGear to load with a fast moving c172p. Instead, the aircraft stands still. Same with --pitch=. If I launch a YASim aircraft with --pitch=60, the aircraft will be positioned like this (see attached screenshot) at startup; JSBSim aircraft just start leveled/normal. Even with --enable-clock-freeze, to make sure they don't tumble over. On the same subject, the Location Location in Air dailog, with JSBSim: *On the ground: airspeed/azimuth/glidepath/ don't seem to work with JSBSim. Heading does work. *In the air: azimuth/glidepath don't seem to work, airspeed appears to be working, but it's hard to say, because the aircraft starts spinning the moment it is re-positioned. Looks like the aircraft is positioned with --pitch=90 no matter what setting... Attachments: fgfs-screen-002.png 330 KB -- You received this message because you were CC'd on the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment or make updates. diff --git a/src/Environment/environment_mgr.cxx b/src/Environment/environment_mgr.cxx index e480390..42023ea 100644 --- a/src/Environment/environment_mgr.cxx +++ b/src/Environment/environment_mgr.cxx @@ -97,6 +97,13 @@ FGEnvironmentMgr::init () SG_LOG( SG_GENERAL, SG_INFO, Initializing environment subsystem); SGSubsystemGroup::init(); fgClouds-Init(); + + // Initialize the longitude, latitude and altitude to the initial position + // of the aircraft so that the atmospheric properties (pressure, temperature + // and density) can be initialized accordingly. + _altitudeNode-setDoubleValue(fgGetDouble(/sim/presets/altitude-ft)); + _longitude_n-setDoubleValue(fgGetDouble(/sim/presets/longitude-deg)); + _latitude_n-setDoubleValue(fgGetDouble(/sim/presets/latitude-deg)); } void diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx index 806401c..54ed598 100644 --- a/src/FDM/JSBSim/JSBSim.cxx +++ b/src/FDM/JSBSim/JSBSim.cxx @@ -181,7 +181,7 @@ FGJSBsim::FGJSBsim( double dt ) MassBalance = fdmex-GetMassBalance(); Propulsion = fdmex-GetPropulsion(); Aircraft= fdmex-GetAircraft(); -Propagate= fdmex-GetPropagate(); +Propagate = fdmex-GetPropagate(); Auxiliary = fdmex-GetAuxiliary(); Inertial= fdmex-GetInertial(); Aerodynamics= fdmex-GetAerodynamics(); @@ -369,9 +369,9 @@ void FGJSBsim::init() Atmosphere-UseInternal(); } -fgic-SetVNorthFpsIC( -wind_from_north-getDoubleValue() ); -fgic-SetVEastFpsIC( -wind_from_east-getDoubleValue() ); -
Re: [Flightgear-devel] release discussion
2011/4/15 ThorstenB bre...@gmail.com: Ok, not sure what has changed there, but is it important enough to be migrated to 2.2? I know it's tempting to make all the new features available right now (I'd like to see my new TCAS in the release, we've had 2 JSBSim updates, new HLA support, tank properties, joystick reloading, of course many many really nice Aircraft updates...). But they are not release-blocking. Last 2.2.0 fixes were applied on February 19th. I'll have a look at the commits on next/master since then. Anyone else aware of missing and release-blocking commits apart from the Models subdirectory? cheers, Thorsten Hi Thorsten, Yes, a bug fix has been committed to fix instant replay with JSBSim aircraft (bug #294) https://gitorious.org/fg/flightgear/commit/11320e6b008eb85b8dff66a137f671743cc04580 I think it should be applied to 2.2.0 as well. Bertrand. -- 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] Heads up: AI/ATC interactions
2011/4/12 Durk Talsma durkt...@gmail.com: Hi All, after a slightly longer than expected break from FlightGear, I started picking up coding again about a week or two ago. I am currently working integrating the AIModels based traffic system with an ATC system in which the user can also participate. It's going to be similar to the system that David Luff has been working on for a long time, and is basically intended to be a replacement of his AI/ATC code (in mutual agreement with David). In some respects it's also similar to the ATC system from FS2004. But, I will follow my own intuitions in implementing this system. The last weeks, I've been mainly working on getting reaquainted with the inner workings of FlightGear. Most specifically, finding out how the AI system actually worked and finding out how to read a keyboard command from a GUI dialog box. Today, I had my first minor success by managing to let my own aircraft request permission for engine startup while parked at the B terminal at EHAM. I managed to re-use a lot of classes that were originally designed for AI use, and today's engine startup clearance was still accomplished through the AI system. (i.e., it was my AI copilot doing the talking. When it comes to user interactions, the next logical move will obviously be to block ATC transmissions that are initiated by the AI co-pilot, although it might be interesting to keep this as an option (see below). I still need to look at the details, but this should be quite doable. As a slightly unexpected bonus, today I realized that I can use all the relevant classes from the AIModels and traffic manager system here and set them up to reflect the user's aircraft in the AI world, without actually interfering with the AIModels and traffic manager subsystems. In doing so, I realize that there are some interesting future possibilities: 1) Let the AI system create a flight plan for the user aircraft and use this flightplan eiter for VFR or IFR flight planning 2) Let the ATC system handle the comm radio and let it serve as a virtual co-pilot. 3) Build a simple light-weight flight planner into FlightGear 4) Possibly a lot more that I haven't even thought of From this initial success, it's probably still going to take a long road before I have a fully fully functional system up and running, so it may take a while before I will commit this to get. Nevertheless, I just wanted share this minor triumph with you all and to give a quick heads up with respect to my current flightgear whereabouts. Cheers, Durk This looks very exciting ! Bertrand. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
Hi,
I could reproduce the bug on my computer as well.
There seems to be some confusion about what the
SetLongitude()/SetLatitude()/SetAltitude()/etc. do in
src/FDM/JSBSim/JSBSim.cxx. On one hand, they are obviously intended to
update the initial conditions (IC) of JSBSim. And, when the IC are
updated, JSBSim assumes that a trim is needed. This is what happens when
the FDM is initialized or reset.
On the other hand, during a replay, these same functions are called but
with a somewhat different goal. Obviously the intent of 'replay' is not
to modify the IC of JSBSim but to fake the calculations of the FDM for
the purpose of displaying the aircraft at the right location and right
attitude. In this case there is indeed no need for a trim.
These two purposes are not really consistent hence the problem : JSBSim
gets lost about what the intent of FlightGear is.
Attached is a patch that fixes this bug (#294 in the bug tracker). As
far as I could test, it restores the functionality of the instant replay
while keeping the restart feature (CTRL+SHIFT+ESC) functional.
Furthermore I have implemented the 2 methods suspend() and resume() in
JSBSim.cxx so that the FDM is actually suspended during the replay.
However this bug fix is not really elegant because the original code is
not so elegant itself (see explanations above).
Bertrand.
Le lundi 21 mars 2011 à 20:06 +0100, ThorstenB a écrit :
Hi,
not sure if anyone else had a chance to test the instant replay with
JSBSim aircraft - but it indeed seems like a general issue to me. It's
triggered by JSBSim doing a trim operation once playback has
finished - which produces an output like this (with the F16 in this
case):
Trim Results:
Altitude AGL: 15 wdot: -1.83e+08 Tolerance: 1e-03 Failed
Pitch Angle:-19 qdot: 9.33e+07 Tolerance: 1e-04 Failed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 0 average: 0 successful: 0 stability: 3.5272
qdot: 0 average: 0 successful: 0 stability: 3
Run Count: 1201
Soon afterwards, the entire sim locks up since the FDM numerics go
wild. I can avoid this issue by suppressing the re-trim when replay
has finished (by forcing needTrim = false; in the code). All works
well for me then - but it completely kills the needTrim feature in
JSBSim, which was probably implemented for a reason...
The trim is triggered since the FDM still has its property listeners
connected during replay - so it thinks the aircraft position changes,
which sets the FDM's needTrim flag. Might be a good idea to
disconnect the FDM property ties during a replay - but JSBSim
currently doesn't allow to reconnect the ties (bind method is not
implemented). And the basic problem here probably is just that
something with re-trimming an aircraft doesn't work properly.
Any ideas on what could go wrong when the FDM tries to trim an already
trimmed aircraft?
cheers,
Thorsten
On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB bre...@gmail.com wrote:
I'm seeing an issue with the instant replay feature which seems to affect
JSBSim aircraft. The actual replay works, but once replay is finished, the
sim locks up or goes wild when trying to resume normal flight. Looks to me
as if the FDM was somehow messed up by the replay. The FDM's update is
suspended during replay - but I suspect there may be an issue with the tied
properties, which still allow the FDM to see the replayed movements. YASim
aircraft seem to be fine though.
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0eb2188..e2d98b6 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -570,6 +570,22 @@ void FGJSBsim::update( double dt )
/**/
+void FGJSBsim::suspend()
+{
+ fdmex-Hold();
+ SGSubsystem::suspend();
+}
+
+/**/
+
+void FGJSBsim::resume()
+{
+ fdmex-Resume();
+ SGSubsystem::resume();
+}
+
+/**/
+
// Convert from the FGInterface struct to the JSBsim generic_ struct
bool FGJSBsim::copy_to_JSBsim()
@@ -1011,7 +1027,9 @@ void FGJSBsim::set_Latitude(double lat)
_set_Sea_level_radius( sea_level_radius_meters * SG_METER_TO_FEET );
fgic-SetSeaLevelRadiusFtIC( sea_level_radius_meters * SG_METER_TO_FEET );
fgic-SetLatitudeRadIC( lat_geoc );
-needTrim=true;
+
+if
Re: [Flightgear-devel] Possessiveness
Thank you all for your responses. I now feel reassured that the Flight Gear community has not lost its common sense. Cheers, Bertrand. -- 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
[Flightgear-devel] Possessiveness
Hi all, When I read this (for such a trivial change it looks very much like an overreaction) http://gitorious.org/fg/fgdata/commit/ad77bef24665b27539a07423cf7a199fa75a19b8#comment_42848 and that : 2011/2/23 Heiko Schulz aeitsch...@yahoo.de: We had this dicussion already. Every developer has the right to refuse any contribution. You have the right on your AH-1 as well. And though it is a pity that Horacio's work hasn't been included, the right of the main developer to decide what contribution he will accept is above all. it raises my eyebrows. Should we now track the paternity of every single file and humbly cry for permission from the *main Developer* (with a capital 'D') of the aforementioned file for every single commit ? Or do we want to be pragmatic and accept that once a file is committed under GPL in git, any contributor has the same rights (no more but no less) than the original author ? Bertrand. -- 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] Simgear and OSG out of sync?
2011/2/17 Tim Moore timoor...@gmail.com: I've committed one more fix that should make things right on 2.8.3. Tim It works now with OSG 2.8.1 ! Thanks Tim. Bertrand. -- 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] Simgear and OSG out of sync?
My patch may not work for OSG =2.9 but the fact is that _readerWriterOptions is also needed for SimGear to compile with OSG 2.8.1. Cheers, Bertrand Le 16 févr. 2011 02:53, Frederic Bouvier fredfgf...@free.fr a écrit : - Bertrand Coconnier a écrit : 2011/2/15 Tim Moore timoor...@gmail.com: I've checked in fixes for this change in osgDB:Dat... Your patch doesn't work for OSG = 2.9 because _readerWriterOptions is unconditionally used in SGPagedLOD.cxx Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- 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... -- 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] Simgear and OSG out of sync?
2011/2/15 Tim Moore timoor...@gmail.com: I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Part of the delay resulted from the fact that the Open Scene Graph change introduced a new bug; I have waited until my patch for that was accepted in OSG to avoid a situation where people could compile with OSG SVN and then crash immediately. So, You need to have revision 12170 or later of OSG SVN in order to run fgfs from the release and next branches. Otherwise you should use OSG 2.8.3 or 2.9.10. I will not conditionalize code in fgfs based on individual revisions of OSG SVN; if you are using OSG SVN, then you are, by definition, living on the bleeding edge. Hi Tim, Your commit broke SimGear for me (using OSG 2.8.1). I have attached a tiny patch that restores the ability to compile the last SG git revision with OSG 2.8.1 Could you please review it and apply it if it makes sense ? Thanks. Bertrand. diff --git a/simgear/scene/model/SGPagedLOD.hxx b/simgear/scene/model/SGPagedLOD.hxx index a9e55d9..4e25931 100644 --- a/simgear/scene/model/SGPagedLOD.hxx +++ b/simgear/scene/model/SGPagedLOD.hxx @@ -72,7 +72,7 @@ public: protected: virtual ~SGPagedLOD(); -#if SG_PAGEDLOD_HAS_OPTIONS +#if !SG_PAGEDLOD_HAS_OPTIONS osg::ref_ptrosgDB::ReaderWriter::Options _readerWriterOptions; #endif }; -- 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
Enough of that please. I would be grateful if both of you AJ MacLeod and Alasdair ould stop polluting everyone's mail box with your discussion. Thank you very much. Bertrand. -- 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
Correct. JSBSim itself makes no distinction between ground materials (hence the reason why some aircrafts are able to land on water). This can however be managed with Nasal scripts. So I would say that this issue is likely located in one of the C172 Nasal scripts. Bertrand Le 10 févr. 2011 09:19, Ron Jensen w...@jentronics.com a écrit : On Thursday 10 February 2011 06:09:56 Geoff McLane wrote: On Wed, 2011-02-09 at 19:51 +, Marti... As far as I know, JSBSim still doesn't know about surfaces? Ron -- The ultimate all-in-... -- 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] JSBSIM Aircraft Crash at Reset
2011/2/5 ThorstenB bre...@gmail.com:
On 05.02.2011 16:21, ThorstenB wrote:
I'm currently testing a different patch for the same issue: instead of
untieing all properties below the /fdm/jsbsim (only), I added a list
to JSBSim's FGPropertyManagager, so it keeps track of all the
properties it has actually bound. It can then use this list to untie
all its properties - no matter where these are located in the
property tree.
New patch pushed to flightgear/next:
http://www.gitorious.org/fg/flightgear/commit/ad8d46ba648263630b8777c53f852b75cad7ecdd
This will be overwritten by the next JSBSim update, however it's a
short-term fix and candidate for our pending 2.2 release.
So, please test if you still see reset issues with JSBSim aircraft. If
we find it's an improvement (maybe/hopefully the final fix for this
issue), then we'll be pushing this to the 2.2 branch also. But remember,
none of the reset fixes is part of the 2.2 branch just yet.
The long term fix needs to be part of the JSBSim repository of course.
Jon, Erik: please check if you want to use this patch or have some other
solution to the problem.
Hi Thorsten,
Good catch ! I had a quick look at your patch and have a couple of
comments on it :
* Some templates of the Tie() method are located in
FGPropertyManager.h and have been overlooked in your patch (this is
quite important because it leaves a hole in the bottom of which some
bugs may have stayed hidden)
* I would only add the successfully tied properties to the
tied_properties list. In your patch the name of the properties are
unconditionally added to the list. I don't think that does any harm
but the code now looks cleaner to me.
* The method FGFDMExec::checkTied() is now redundant with
FGPropertyManager::Unbind() so the former has been removed in favour
of the latter (this one is rather internal JSBSim stuff, I have
included it for the sake of completeness).
* I would rather make tied_properties a list of SGPropertyNode* rather
than a list of strings (same as above : internal JSBSim stuff)
* Traditionally, method names in JSBSim have the first letter of their
name capitalized (very very minor this one !)
Attached patch includes all the above suggestions. The patch has been
made against the last revision of the 'next' branch of git.
Wow ! This issue is really hard to fix. However it exemplifies the
Open Source model superiority in allowing such a team work to fix
quite a reluctant and annoying bug.
Cheers,
Bertrand.
diff --git a/src/FDM/JSBSim/FGFDMExec.cpp b/src/FDM/JSBSim/FGFDMExec.cpp
index b3b7003..ade4209 100644
--- a/src/FDM/JSBSim/FGFDMExec.cpp
+++ b/src/FDM/JSBSim/FGFDMExec.cpp
@@ -78,22 +78,6 @@ static const char *IdHdr = ID_FDMEXEC;
CLASS IMPLEMENTATION
%%*/
-void checkTied ( FGPropertyManager *node )
-{
- int N = node-nChildren();
- string name;
-
- for (int i=0; iN; i++) {
-if (node-getChild(i)-nChildren() ) {
- checkTied( (FGPropertyManager*)node-getChild(i) );
-}
-if ( node-getChild(i)-isTied() ) {
- name = ((FGPropertyManager*)node-getChild(i))-GetFullyQualifiedName();
- node-Untie(name);
-}
- }
-}
-
//%%
// Constructor
@@ -185,7 +169,7 @@ FGFDMExec::FGFDMExec(FGPropertyManager* root, unsigned int* fdmctr) : Root(root)
FGFDMExec::~FGFDMExec()
{
try {
-checkTied( instance );
+Unbind();
DeAllocate();
if (IdFDM == 0) { // Meaning this is no child FDM
diff --git a/src/FDM/JSBSim/FGFDMExec.h b/src/FDM/JSBSim/FGFDMExec.h
index c1038c4..b982654 100644
--- a/src/FDM/JSBSim/FGFDMExec.h
+++ b/src/FDM/JSBSim/FGFDMExec.h
@@ -227,7 +227,7 @@ public:
~FGFDMExec();
/** Unbind all tied JSBSim properties. */
- void unbind(void) {instance-unbind();}
+ void Unbind(void) {instance-Unbind();}
/** This routine places a model into the runlist at the specified rate. The
rate is not really a clock rate. It represents how many calls to the
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0cc0025..b1daa9c 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -424,7 +424,7 @@ void FGJSBsim::init()
void FGJSBsim::unbind()
{
- fdmex-unbind();
+ fdmex-Unbind();
FGInterface::unbind();
}
diff --git a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
index 899565e..01f269b 100755
--- a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
+++ b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
@@ -49,16 +49,16 @@ COMMENTS, REFERENCES, and NOTES [use class documentation below for API docs]
namespace JSBSim {
bool FGPropertyManager::suppress_warning = true;
-std::vectorstd::string FGPropertyManager::tied_properties;
+std::vectorSGPropertyNode* FGPropertyManager::tied_properties;
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/5 Jon S. Berndt jonsber...@comcast.net: I'll have to go back and look at the [JSBSim] code again. I'd like to figure out how to make resetting work better from the API - more naturally and without having to reload the aircraft model. This would be useful for both the JSBSim standalone executable and for any larger simulation framework that incorporates JSBSim. Hi Jon, You may already know that but the current behaviour of Flight Gear reset process is coded at a higher level than JSBSim glue code (JSBSim.cxx). The reset process is to unbind - delete - create a new instance of the FDM no matter which FDM is used in Flight Gear (check FDMShell:reinit() in src/FDM/fdm_shell.cxx). So in order to make Flight Gear use the improvements you are mentioning, this will need to be a joint effort between Flight Gear, JSBSim and possibly the developers of the other FDMs. However this should not prevent this improvement to be made on JSBSim side :-) Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ 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
2011/1/30 Bertrand Coconnier bcoco...@gmail.com: 2011/1/29 Ron Jensen w...@jentronics.com: + double fuelDensity = Propulsion-GetTank(i)-GetDensity(); ( ... ) + Propulsion-GetTank(i)-GetContents() / fuelDensity); Should we guard against GetDensity() returning 0? Correct. Please find an updated version of the patch that uses the standard fuel density (6.0 lbs/gal) if the density is too low or negative ( 0.1). This is assuming that if the density goes below that threshold it can only be an error. Another policy would be to clamp the value to 0.1. Suggestions ? Also, unlike the existing code base, this patch is assuming that the fuel weight is the reference and that the fuel volume should be adjusted to the fuel density modifications. When the fuel temperature drops, its volume decreases but its weight is not changing. I would think that this does not break backward compatibility : the fuel/payload menu is checking the fuel volume against the tank capacity and is reacting well to density modifications in the property tree. But I would like to have other opinions. This version 3 of the patches supersedes the other two. Hi FG developers, Since no further comments have been made, is there any chance to see this patch committed in Flight Gear ? In case you would have additional comments or questions before committing, I am of course open to answer them Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 ThorstenB bre...@gmail.com:
Hi Betrand,
thanks for your patch. Only one comment on your patch though...
On Sun, Feb 6, 2011 at 1:08 PM, Bertrand Coconnier bcoco...@gmail.com wrote:
* I would rather make tied_properties a list of SGPropertyNode* rather
than a list of strings (same as above : internal JSBSim stuff)
I don't really like the use of simple pointers here, as property
objects sometimes are being worked on/merged/deleted. I remember
debugging several issues where modules obtained direct pointers to
properties and then kept using these though the original object was
already deleted/merged/recreated in other parts of FG. Results in ugly
heap issues...
This may not be an issue here (right now), but if we don't want to use
the path name (strings) as a reference, we should probably rather use
a SGSharedPtrSGPropertyNode instead - i.e. the SGPropertyNode_ptr
typedef. This guarantees that the reference is still valid when trying
to untie the property later on.
Thanks for your comments Thorsten.
Here is the patch with the tied_properties list using strings as per
your comment. We may have further discussion on the JSBSim mailing
list as to whether it is better to use SGPropertyNode_ptr or path
names. But since it makes no difference to Flight Gear, I see no
reason to annoy everybody with that. Hence this new patch (that
supersedes the previous one).
Cheers,
Bertrand.
diff --git a/src/FDM/JSBSim/FGFDMExec.cpp b/src/FDM/JSBSim/FGFDMExec.cpp
index b3b7003..ade4209 100644
--- a/src/FDM/JSBSim/FGFDMExec.cpp
+++ b/src/FDM/JSBSim/FGFDMExec.cpp
@@ -78,22 +78,6 @@ static const char *IdHdr = ID_FDMEXEC;
CLASS IMPLEMENTATION
%%*/
-void checkTied ( FGPropertyManager *node )
-{
- int N = node-nChildren();
- string name;
-
- for (int i=0; iN; i++) {
-if (node-getChild(i)-nChildren() ) {
- checkTied( (FGPropertyManager*)node-getChild(i) );
-}
-if ( node-getChild(i)-isTied() ) {
- name = ((FGPropertyManager*)node-getChild(i))-GetFullyQualifiedName();
- node-Untie(name);
-}
- }
-}
-
//%%
// Constructor
@@ -185,7 +169,7 @@ FGFDMExec::FGFDMExec(FGPropertyManager* root, unsigned int* fdmctr) : Root(root)
FGFDMExec::~FGFDMExec()
{
try {
-checkTied( instance );
+Unbind();
DeAllocate();
if (IdFDM == 0) { // Meaning this is no child FDM
diff --git a/src/FDM/JSBSim/FGFDMExec.h b/src/FDM/JSBSim/FGFDMExec.h
index c1038c4..b982654 100644
--- a/src/FDM/JSBSim/FGFDMExec.h
+++ b/src/FDM/JSBSim/FGFDMExec.h
@@ -227,7 +227,7 @@ public:
~FGFDMExec();
/** Unbind all tied JSBSim properties. */
- void unbind(void) {instance-unbind();}
+ void Unbind(void) {instance-Unbind();}
/** This routine places a model into the runlist at the specified rate. The
rate is not really a clock rate. It represents how many calls to the
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0cc0025..b1daa9c 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -424,7 +424,7 @@ void FGJSBsim::init()
void FGJSBsim::unbind()
{
- fdmex-unbind();
+ fdmex-Unbind();
FGInterface::unbind();
}
diff --git a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
index 899565e..c0218ec 100755
--- a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
+++ b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
@@ -53,7 +53,7 @@ std::vectorstd::string FGPropertyManager::tied_properties;
//%%
-void FGPropertyManager::unbind(void)
+void FGPropertyManager::Unbind(void)
{
vectorstring::iterator it;
for (it = tied_properties.begin();it tied_properties.end();it++)
@@ -314,11 +314,12 @@ void FGPropertyManager::Untie (const string name)
void FGPropertyManager::Tie (const string name, bool *pointer, bool useDefault)
{
- tied_properties.push_back(name);
if (!tie(name.c_str(), SGRawValuePointerbool(pointer), useDefault))
cerr Failed to tie property name to a pointer endl;
- else if (debug_lvl 0x20)
-cout name endl;
+ else {
+tied_properties.push_back(name);
+if (debug_lvl 0x20) std::cout name std::endl;
+ }
}
//%%
@@ -326,11 +327,12 @@ void FGPropertyManager::Tie (const string name, bool *pointer, bool useDefault)
void FGPropertyManager::Tie (const string name, int *pointer,
bool useDefault )
{
- tied_properties.push_back(name);
if (!tie(name.c_str(), SGRawValuePointerint(pointer), useDefault))
cerr Failed to tie property name to a pointer endl;
- else if (debug_lvl 0x20)
-cout name endl;
+ else {
+tied_properties.push_back(name
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? It is supposed to be a Flight Gear patch and be applied against last revision of git 'next' branch. Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 Erik Hofman e...@ehofman.com: On Sun, 2011-02-06 at 07:56 -0600, Jon S. Berndt wrote: 2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? BTW, this patch won't apply automatically due to path issues. I am required to enter specific path names to the file. Any ideas how to fix that? Go to JSBSim/src and add '-p 4' to the patch command line. (this skips 4 levels of directory entries) It is not sufficient because Thorsten's patch needs to be applied first. I am building a complete patch against JSBSim and will post in JSBSim mailing list. Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ 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
2011/2/6 Torsten Dreyer tors...@t3r.de: I am currently working on a more generic solution to the issue based on your patch. Currently we have at least three different places within FlightGear calculating tank contents and converting them between different units. The idea is to have a TankProperties class encapsulating all property- conversions and to have the fdm_shell create instances of the class. With that, you can write to any of it's properties (level, capacity, density) using any unit and have all other properties correct. There is no need to have this in every FDM and also in Nasal. I'm curently testing various aircraft on Windows and Linux and I hope to get this commited later today. Greetings, Torsten Great ! Thanks for the update. Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ 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
2011/2/6 Torsten Dreyer tors...@t3r.de:
I'm curently testing various aircraft on Windows and Linux and I hope to get
this commited later today.
Torsten,
I have checked your code and it breaks the previous behaviour for
JSBSim. Your code is overwriting JSBSim values during initialization,
I would rather do it the other way around and make JSBSim overwrite
FlightGear default values. Especially because the capacity of all the
tanks is now set to zero instead of using the FDM model definition.
Enclosed is a patch that restores the normal behaviour : fuel
capacity, level and density are set after the values defined in the
aircraft JSBSim XML definition.
Bertrand.
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index c6f1933..006c66e 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -212,17 +212,21 @@ FGJSBsim::FGJSBsim( double dt )
// Set initial fuel levels if provided.
for (unsigned int i = 0; i Propulsion-GetNumTanks(); i++) {
- double d;
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
FGTank* tank = Propulsion-GetTank(i);
+ double fuelDensity = tank-GetDensity();
+ double contents = tank-GetContents();
- d = node-getNode( density-ppg, true )-getDoubleValue();
- if( d 0.0 )
-tank-SetDensity( d );
+ if (fuelDensity 0.0) {
+double capacity = tank-GetCapacity();
- d = node-getNode( level-lbs, true )-getDoubleValue();
- if( d 0.0 )
-tank-SetContents( d );
+node-setDoubleValue(density-ppg, fuelDensity);
+if (capacity 0.0)
+ node-setDoubleValue(capacity-gal_us, capacity / fuelDensity);
+ }
+
+ if (contents 0.0)
+node-setDoubleValue(level-lbs, contents);
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
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
2011/2/6 Torsten Dreyer tors...@t3r.de: I tried the few JSBSim and YASim aircraft that I'm able to handle, please report if I broke anything. Have you read my previous e-mail ? I attached a patch because JSBSim fuel calcs are broken (tested aircraft is p51d). All P51d tank capacities, levels and fuel densities are wrongly overwritten and set to 0.0 (except the density which is set to 6.3 lbs/gal instead of 6.02 lbs/gal). Jester tested my patch as well and reported it to work. Could you please check and give me your comments ? Thanks Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ 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
2011/1/29 Ron Jensen w...@jentronics.com:
+ double fuelDensity = Propulsion-GetTank(i)-GetDensity();
( ... )
+ Propulsion-GetTank(i)-GetContents() / fuelDensity);
Should we guard against GetDensity() returning 0?
Correct.
Please find an updated version of the patch that uses the standard
fuel density (6.0 lbs/gal) if the density is too low or negative (
0.1). This is assuming that if the density goes below that threshold
it can only be an error. Another policy would be to clamp the value to
0.1.
Suggestions ?
Also, unlike the existing code base, this patch is assuming that the
fuel weight is the reference and that the fuel volume should be
adjusted to the fuel density modifications. When the fuel temperature
drops, its volume decreases but its weight is not changing. I would
think that this does not break backward compatibility : the
fuel/payload menu is checking the fuel volume against the tank
capacity and is reacting well to density modifications in the property
tree. But I would like to have other opinions.
This version 3 of the patches supersedes the other two.
Cheers,
Bertrand.
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index a9e9be7..2e75e44 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -213,14 +213,28 @@ FGJSBsim::FGJSBsim( double dt )
// Set initial fuel levels if provided.
for (unsigned int i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
+ FGTank* tank = Propulsion-GetTank(i);
+ double fuelDensity;
+
+ if (node-getChild(density-ppg, 0, false) != 0) {
+fuelDensity = node-getDoubleValue(density-ppg);
+tank-SetDensity(fuelDensity);
+ }
+ else {
+fuelDensity = tank-GetDensity();
+node-setDoubleValue(density-ppg, fuelDensity);
+ }
+
+ if (fuelDensity 0.1)
+fuelDensity = 6.0; // Use average fuel value
+
if (node-getChild(level-gal_us, 0, false) != 0) {
-Propulsion-GetTank(i)-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
+tank-SetContents(node-getDoubleValue(level-gal_us) * fuelDensity);
} else {
-node-setDoubleValue(level-lbs, Propulsion-GetTank(i)-GetContents());
-node-setDoubleValue(level-gal_us, Propulsion-GetTank(i)-GetContents() / 6.6);
+node-setDoubleValue(level-lbs, tank-GetContents());
+node-setDoubleValue(level-gal_us, tank-GetContents() / fuelDensity);
}
- node-setDoubleValue(capacity-gal_us,
- Propulsion-GetTank(i)-GetCapacity() / 6.6);
+ node-setDoubleValue(capacity-gal_us, tank-GetCapacity() / fuelDensity);
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
@@ -695,8 +709,14 @@ bool FGJSBsim::copy_to_JSBsim()
for (i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
FGTank * tank = Propulsion-GetTank(i);
- tank-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
-// tank-SetContents(node-getDoubleValue(level-lbs));
+ double fuelDensity = node-getDoubleValue(density-ppg);
+
+ if (fuelDensity 0.1)
+fuelDensity = 6.0; // Use average fuel value
+
+ tank-SetDensity(fuelDensity);
+// tank-SetContents(node-getDoubleValue(level-gal_us) * fuelDensity);
+ tank-SetContents(node-getDoubleValue(level-lbs));
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
@@ -934,7 +954,13 @@ bool FGJSBsim::copy_from_JSBsim()
FGTank* tank = Propulsion-GetTank(i);
double contents = tank-GetContents();
double temp = tank-GetTemperature_degC();
-node-setDoubleValue(level-gal_us, contents/6.6);
+double fuelDensity = tank-GetDensity();
+
+if (fuelDensity 0.1)
+ fuelDensity = 6.0; // Use average fuel value
+
+node-setDoubleValue(density-ppg , fuelDensity);
+node-setDoubleValue(level-gal_us, contents/fuelDensity);
node-setDoubleValue(level-lbs, contents);
if (temp != -.0) node-setDoubleValue(temperature_degC, temp);
}
--
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] Fix for bugs #47 and #184
Hi all, Please find attached a patch that fixes bugs #47 and #184. It restores functionality of command line arguments --vc, --roll-deg, --pitch-deg, etc. Note also that this patch has also a positive side effect : it restores functionality of the 'airspeed (kt)' cell of the 'Position Aircraft in air' dialog box. Though in most cases, the engines are not started, and the aircraft is just thrown into the air with correct altitude/attitude/airspeed/etc. I have only tested it for JSBSim models. So further tests might be needed. Cheers, Bertrand. diff --git a/src/FDM/flight.cxx b/src/FDM/flight.cxx index 5676e68..d501d15 100644 --- a/src/FDM/flight.cxx +++ b/src/FDM/flight.cxx @@ -268,15 +268,15 @@ FGInterface::bind () // Orientation fgTie(/orientation/roll-deg, this, FGInterface::get_Phi_deg, - FGInterface::set_Phi_deg); + FGInterface::set_Phi_deg, false); fgSetArchivable(/orientation/roll-deg); fgTie(/orientation/pitch-deg, this, FGInterface::get_Theta_deg, - FGInterface::set_Theta_deg); + FGInterface::set_Theta_deg, false); fgSetArchivable(/orientation/pitch-deg); fgTie(/orientation/heading-deg, this, FGInterface::get_Psi_deg, - FGInterface::set_Psi_deg); + FGInterface::set_Psi_deg, false); fgSetArchivable(/orientation/heading-deg); fgTie(/orientation/track-deg, this, FGInterface::get_Track); @@ -331,11 +331,11 @@ FGInterface::bind () // LaRCSim are fixed (LaRCSim adds the // earth's rotation to the east velocity). fgTie(/velocities/speed-north-fps, this, - FGInterface::get_V_north, FGInterface::set_V_north); + FGInterface::get_V_north, FGInterface::set_V_north, false); fgTie(/velocities/speed-east-fps, this, - FGInterface::get_V_east, FGInterface::set_V_east); + FGInterface::get_V_east, FGInterface::set_V_east, false); fgTie(/velocities/speed-down-fps, this, - FGInterface::get_V_down, FGInterface::set_V_down); + FGInterface::get_V_down, FGInterface::set_V_down, false); fgTie(/velocities/north-relground-fps, this, FGInterface::get_V_north_rel_ground); -- 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] Incorrect conversion used for lbs to gallon of fuel
2011/1/28 Hal V. Engel hven...@gmail.com:
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.
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index f802c8c..c752e5e 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -215,14 +213,15 @@ FGJSBsim::FGJSBsim( double dt )
// Set initial fuel levels if provided.
for (unsigned int i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
+ double fuelDensity = Propulsion-GetTank(i)-GetDensity();
if (node-getChild(level-gal_us, 0, false) != 0) {
-Propulsion-GetTank(i)-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
+Propulsion-GetTank(i)-SetContents(node-getDoubleValue(level-gal_us) * fuelDensity);
} else {
node-setDoubleValue(level-lbs, Propulsion-GetTank(i)-GetContents());
-node-setDoubleValue(level-gal_us, Propulsion-GetTank(i)-GetContents() / 6.6);
+node-setDoubleValue(level-gal_us, Propulsion-GetTank(i)-GetContents() / fuelDensity);
}
node-setDoubleValue(capacity-gal_us,
- Propulsion-GetTank(i)-GetCapacity() / 6.6);
+ Propulsion-GetTank(i)-GetCapacity() / fuelDensity);
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
@@ -670,7 +696,7 @@ bool FGJSBsim::copy_to_JSBsim()
for (i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
FGTank * tank = Propulsion-GetTank(i);
- tank-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
+ tank-SetContents(node-getDoubleValue(level-gal_us) * Propulsion-GetTank(i)-GetDensity());
// tank-SetContents(node-getDoubleValue(level-lbs));
}
--
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] Incorrect conversion used for lbs to gallon of fuel
A better improved patch that supersedes the previous FuelDensity.diff
I sent to this list.
This one takes /consumables/fuel/tank[n]/density-ppg into account in the calcs.
Cheers,
Bertrand.
2011/1/29 Bertrand Coconnier bcoco...@gmail.com:
2011/1/28 Hal V. Engel hven...@gmail.com:
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.
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index f802c8c..fc09b0b 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -215,14 +213,25 @@ FGJSBsim::FGJSBsim( double dt )
// Set initial fuel levels if provided.
for (unsigned int i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
+ FGTank* tank = Propulsion-GetTank(i);
+ double fuelDensity;
+
+ if (node-getChild(density-ppg, 0, false) != 0) {
+fuelDensity = node-getDoubleValue(density-ppg);
+tank-SetDensity(fuelDensity);
+ }
+ else {
+fuelDensity = tank-GetDensity();
+node-setDoubleValue(density-ppg, fuelDensity);
+ }
+
if (node-getChild(level-gal_us, 0, false) != 0) {
-Propulsion-GetTank(i)-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
+tank-SetContents(node-getDoubleValue(level-gal_us) * fuelDensity);
} else {
-node-setDoubleValue(level-lbs, Propulsion-GetTank(i)-GetContents());
-node-setDoubleValue(level-gal_us, Propulsion-GetTank(i)-GetContents() / 6.6);
+node-setDoubleValue(level-lbs, tank-GetContents());
+node-setDoubleValue(level-gal_us, tank-GetContents() / fuelDensity);
}
- node-setDoubleValue(capacity-gal_us,
- Propulsion-GetTank(i)-GetCapacity() / 6.6);
+ node-setDoubleValue(capacity-gal_us, tank-GetCapacity() / fuelDensity);
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
@@ -670,7 +706,9 @@ bool FGJSBsim::copy_to_JSBsim()
for (i = 0; i Propulsion-GetNumTanks(); i++) {
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
FGTank * tank = Propulsion-GetTank(i);
- tank-SetContents(node-getDoubleValue(level-gal_us) * 6.6);
+ double fuelDensity = node-getDoubleValue(density-ppg);
+ tank-SetDensity(fuelDensity);
+ tank-SetContents(node-getDoubleValue(level-gal_us) * fuelDensity);
// tank-SetContents(node-getDoubleValue(level-lbs));
}
@@ -909,7 +947,9 @@ bool FGJSBsim::copy_from_JSBsim()
FGTank* tank = Propulsion-GetTank(i);
double contents = tank-GetContents();
double temp = tank-GetTemperature_degC();
-node-setDoubleValue(level-gal_us, contents/6.6);
+double fuelDensity = tank-GetDensity();
+node-setDoubleValue(density-ppg , fuelDensity);
+node-setDoubleValue(level-gal_us, contents/fuelDensity);
node-setDoubleValue(level-lbs, contents);
if (temp != -.0) node-setDoubleValue(temperature_degC, temp);
}
--
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] Tried to initialize a non-existent engine!
Hi all, I think I have a final bug fix for JSBSim reset issues (bug #204 and #222). I have investigated James Turner's fix and tried to understand why it fixes the issue in every case but for gliders. NaNs (bug #222) were basically generated because the method JSBSim::unbind() was not implemented in JSBSim.cxx. Thus when globals-get_subsystem(flight)-unbind(); (src/Main/fg_init.cxx line 1538) was executed, FG properties were unbound but JSBSim properties were not. The NaNs were then triggered afterwards when globals-restoreInitialState(); was called because JSBSim listeners were still active and triggered the execution of routines (trim for instance) which should not have been called at this stage of the reset process. By implementing the unbind() method in JSBSim.cxx, there are no listeners remaining when restoreInitialState is called and JSBSim routines are no longer unexpectedly called. The second bug Tried to initialize a non-existent engine is removed by setting the useDefault parameter to false when calling FGPropertyManager::Tie() in src/FDM/JSBSim/models/FGPropulsion.cpp line 649. This bug was triggered because the tie() method of SGPropertyNode remembers the setter/getter that were set on the property propulsion/set-running when it was created. When FG is resetting, JSBSim re-builds this property. When asked to re-use the default value, SGPropertyNode::tie() calls the setter of the property propulsion/set-running which is InitRunning() in this case. Because no engines are created yet, InitRunning() complains that we are trying to initialize a non-existent engine. The simplest way to fix this bug is to ask SGPropertyNode::tie() not to set propulsion/set-running to its default value. That prevents the setter InitRunning() to be called. As far as I can see, JSBSim uses SGPropertyNode::Tie() with useDefault set to true in many places. This may be a potential source of similar bugs in other places. I wonder if JSBSim should not better set useDefault to false instead ? But that is a topic for JSBSim developers mailing list. Cheers, Bertrand. 2011/1/28 henri orange hohora...@gmail.com: Continued I can notice, the older fgfs version without James Turner Patch, was right with Gliders ( no Engines ). My conclusion, the James Turner Patch was right to solve the issue, Aircraft with engine related, however it makes an issue, Aircraft without engine related. Sorry James, your patch does not fix correctly the bug. 2011/1/28 henri orange hohora...@gmail.com BTW: paraglider is getting the same issue 2011/1/28 henri orange hohora...@gmail.com Hello devel members, Again, the issue . Not with Aircraft's Engine, since the patch solved it (though getting others randomly bugs) but with Aircraft WITHOUT Engine, like Gliders . Tested with sgs233. Whould be the same issue with others JSBSim gliders 2011/1/25 James Turner zakal...@mac.com On 25 Jan 2011, at 10:28, Jon S. Berndt wrote: What patch? FIx for #204, the issue Henri is describing: http://gitorious.org/fg/flightgear/commit/c2458a17bf0a8a95caf1a43e37482162ae0100bc Partial band-aid for #222, the reset-NaN crash: (ugly, but not in the main JSBSim code) http://gitorious.org/fg/flightgear/commit/4b494b1d0842bc53d7295f74c44cf4f7a3185446 Andreas' other fixes for #222: http://gitorious.org/fg/flightgear/commit/4f364af6d178d947eae1a5a751e3a9542b270069 Regards, James -- 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 -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- 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 diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx index f802c8c..a9e9be7 100644 --- a/src/FDM/JSBSim/JSBSim.cxx +++ b/src/FDM/JSBSim/JSBSim.cxx @@ -144,8 +144,6 @@ FGJSBsim::FGJSBsim(
Re: [Flightgear-devel] JSBSim merge
2011/1/26 Erik Hofman e...@ehofman.com: After a bit of discussion it was decided that the FlightGear/JSBSim glue code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is maintained by FlightGear developers instead of by JSBSim developers and therefore these files will not be overwritten in future updates. I don't know where this discussion took place so I may have missed the juicier bits. Then I apologize in advance if my questions have already been answered. Instead they are now copied over to JSBSim instead to act as example code. Given the decisions taken above, I don't understand why, in the first place, JSBSim should keep a copy of some code that will now be maintained elsewhere ? What is the plan ? Porting all patches from FlightGear to JSBSim's copy ? What for ? AFAICT JSBSim stand-alone executable is itself an example of how to integrate JSBSim library in an executable. And JSBSim.[ch]xx seems a fairly complicated chunk of code to serve as an example. For instance, JSBSim.cpp (the stand-alone executable) contains 635 lines of code while JSBSim.cxx (the glue code) contains 1413 lines of code. Even though, why the name of the Flight Gear glue code has been changed from JSBSim.[ch]xx to FlightGear.[ch]xx in JSBSim ? Now we have 2 copies of the same source code with 2 different file names. What is the point of this renaming ? Is it not confusing ? 2011/1/26 Erik Hofman e...@ehofman.com: On Wed, 2011-01-26 at 07:19 -0600, Jon S. Berndt wrote: I have received and applied patches from several places recently. Make sure that patches are not accidentally reversed. They won't since the patches at the FlightGear side will be overwritten by what JSBSim had in CVS. Unless I am mistaken, the plan is now to have a 2-way code exchange between FlightGear and JSBSim : FG = JSBSim for JSBSim.[ch]xx/FlightGear.[ch]xx JSBSim = FG for other JSBSim files. Who will make sure that those files are always in a consistent state ? Let's take an example : let's say I develop some code for JSBSim to take into account FG ground material in the landing gears friction forces. For that, I need to modify both JSBSim library *and* FlightGear glue code. So I will submit a patch to JSBSim (for the friction calcs) and another patch to FlightGear (to give JSBSim access to FG material data). The patch for FG glue code cannot be applied readily : first JSBSim needs to be patched and then copied in FlightGear (or otherwise FG compilation will fail). Once JSBSim last revision is copied in FlightGear the second part of the patch must be committed immediately in FlightGear (otherwise FG compilation will fail). And then the patched glue code will be copied back in JSBSim. Notice that the patch can be applied at any moment in JSBSim, even 1 month or 1 year after its submission. On the other hand, some tight synchronization is needed on the FlightGear side if you don't want FG compilation to break. Do you think such a process is sustainable ? I don't. Cheers, Bertrand. -- 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] Carrier Altitude
2011/1/25 Vivian Meazza vivian.mea...@lineone.net: and the vertical movement would tend to unlatch aircraft on deck from the carrier. Are you sure of that statement ? Can the carrier vertical speed be higher than the speed of a falling object ? My bet would be that the normal reaction forces at the landing gears will vary by a fraction of percent rather than unlatching aircrafts ?!? Just my 2 cents. Bertrand. -- 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] Bouncing JSBSim aircraft
2010/11/28 Gijs de Rooy gijsr...@hotmail.com: Hi all, after updating fgdata from Gitorious this evening and installing the win32 nightly binary from Hudson (28-nov-2010 7:00:55), JSBSim aircraft suddenly bounce, when at the ground. Some aircraft bounce more than others (747-400 and C172P for example crash due to the extreme forces), while the followme car only bounces up and down a little. I was able to drive around normally (apart from the bouncing) with the followme. So it looks like it depends on the gear compression/spring settings of the aircraft being operated. The YASim aircraft I tried did not show this behaviour. I suspect the problem arised after this commit by Erik: http://www.gitorious.org/fg/flightgear/commit/ad51a9bde2995605984161af1b4273b28ce4fddc Any clue on what's wrong? Can anyone confirm this behaviour? Cheers, Gijs Hi Gijs, I could not reproduce the problem you described. Tested last git revision for SimGear (1cb8f9237cb7fa47eb8e4a89f135ac17656315a5), FlightGear (1cf207e0540712d3344c48f936a7aade3c5c2797) and data (115032a7c5828c7e82462ca8e57ab0be444d4120). I tried the following commands fgfs --fg-root=/path/to/my/copy/of/fgdata and fgfs --aircraft=747-400 --fg-root=/path/to/my/copy/of/fgdata AFAICT, these are supposed to run the C172P and 747-400. I played a bit with the Cessna (taxiing, taking-off, landing, hard landing, ...) and it behaved correctly. Since I cannot pilot the 747-400, I taxied it a bit and took off and everything went well (well, except that I crashed it while trying to land it). Since I am mostly involved in the landing gears code of JSBSim, I would be interested in having more details about the problem you experienced. Cheers, Bertrand. -- 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] Bouncing JSBSim aircraft
2010/11/28 Gijs de Rooy gijsr...@hotmail.com: Yeah, problems is fixed! I had --model-hz=30. Setting it to 120 (so it was omitted from the commandline by FGRun) fixed the problem. (...snip...) After takeoff, bouncing stops. After landing, bouncing continues. When braking, the intensity of the bounces increases significantly. Apparently not all JSBSim aircraft bounce (see list below). To make a long story short, this kind of behaviour is driven by the eigenfrequencies of the system. They are the frequencies at which a system naturally oscillates. A very rough estimate of these frequencies can be obtained by the square root of k/m where k is the sum of the stiffnesses of all the gears and m is the mass of the airplane. It is thus obvious that this frequency varies from one airplane to the other. As far as I remember, the simulation rate must be as greater as possible than these frequencies otherwise bouncing issues may arise. Hence the disappearance of the issue when you set the simulation time rate back to its default 120 Hz. Cheers and thanks for the help! You are welcome :-) Cheers, Bertrand. -- 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] FGFS-Release was Scenery tile management and further property heads up...
2010/11/21 Tim Moore timoor...@gmail.com: On Sun, Nov 21, 2010 at 2:58 AM, Scott Hamilton scott.hamil...@popplanet.biz wrote: The important point here is that it has been nearly twelve months since the last major release, the codebase appears to be looking forward, and in the past it has required quite a bit of planning and work to ensure we have a consistent and stable product to release. I'm not sure which changes provoked your initial email. The tile manager change is big, but it addresses longstanding, severe bugs. My property tree hash work was also in response to bugs, and I think we've established that it is not in fact a major change. James' work isn't changing anything yet, as far as I know. Part of that work is first finding a suitable point in time and code to take a snapshot of the code, that includes simgear, flightgear and fgdata. Then I think it would be wise to test that snapshot and fix any of the problems that may be uncovered. But before we can start any of that, we have to make a decision to make a release and set a tentative release date. We are going to make a release branch soon. Tim Hi all, I am not myself a developer of Flight Gear but it seems to me that a release branch could already be created now ? It is a cheap decision to make, and an even cheaper action to do. It does not prevent the core code from making progress for the near and far future while allowing the release to be fixed at the same time. All bug fixes would go in both the release and 'next' branch, other development would go in the 'next' branch only. Well, nothing really new but given that FG switched to git a few months ago, why not taking advantage of it ? Just my 2 cents. Cheers, Bertrand. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-400 causing crash of fgfs
2010/10/17 Gijs de Rooy gijsr...@hotmail.com: For example, the current FG747 wing flex is calculated on various thing, one of which is the amount of fuel in each wing section, but how much lift is required to contradict this fuel-force? Gijs, The structural analysis of a wing is a very complex field of engineering but for the sake of a visual representation of the wing bending in Flight Gear, I would say that the wing can be satisfyingly modelled as a cantilever beam of uniform stiffness submitted to a uniform loading. According to Timoshenko's Element of Strength of Materials(1940), the deflection of such a beam at any spanwise station 'x' is d = w*x^2*(x^2+6*b^2-4*b*x)/(E*I) The wing span is b, the wing root is assumed to be at x=0 and the wing tip at x=b. The distributed load 'w' is assumed to be uniformly distributed and should be expressed in lbf/ft or lbf/in In this formula, the sign convention is w0 means the loads are applied downward and d0 means the wing deflects downward as well. The Young modulus E=10,000,000 psi can be guessed because the 747 wings are likely made of aluminium but the beam inertia I (in ft^4 or in^4) is quite difficult to assess without the blue prints (and even with the blue prints by the way). However, here is a small suggestion to use this formula: 1. The loading on the wing is basically the algebraic sum of the wing weight and of the aerodynamic lift. Assuming that the wing deflection under its own weight is of second order (a wing is sized by aerodynamic loads, inertia/manoeuvre/'g' loads and landing loads if the landing gears are attached to the wing), 'w' can be assumed to be proportional to the lift coefficient CL i.e. w = CL*0.5*rho*S*V^2/b where rho is the air density, S the wing area, V the air speed and b the wing span. 2. The maximum deflection at the wing tip being dmax = w*b^4/(8*E*I), if we assume that during a take-off, the wing deflection is 3ft then you can calculate E*I = CL*0.5*rho*S*V*b^3/(8*3ft) (replace V, rho and CL by the appropriate values at take-off). 3. Use the above deflection formula with the values computed in the previous steps. This is a very rough approximation because the wing inertia is not uniform across the span (a wing structure is made of spars and ribs/bulkheads/webs) and the distributed loading is not uniform either (lift forces are not uniform, weight is not uniformly distributed - think about the engines), etc. I hope this helps however. Cheers, Bertrand. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal map shader example - c172p
2010/4/9 Stuart Buchanan stuar...@gmail.com: Frederic Bouvier wrote: Glad to see the effect is used. I noticed the bump is reverted on one axis. In a previous thread, I wrote : I use the GIMP normal map plug-in to create my normal maps. Here are two example. A bump : http://frbouvi.free.fr/flightsim/gimp-normalmap-bump.png A hole : http://frbouvi.free.fr/flightsim/gimp-normalmap-hole.png They are created from the same height field image. Reds should point to the bottom right and greens should points to the top left. More precisely: #FF7F7F points to the right #7FFF7F points to the top #007F7F points to the left #7F007F points to the bottom These are the only two realistic combinations. Remember that for OpenGL the origin of the image is the bottom left when the origin of an image is the top left, so that's why an axis should be reverted. Looking closely at the wing map : http://frbouvi.free.fr/flightsim/gimp-normalmap-c172.png It appears that reds are pointing to the top right and greens to the bottom left. You may need to check the 'Invert Y' box in order to get them right. Thanks for the help. I've updated the normal maps, and included this information in the wiki article. This is some nice artistic/graphical work indeed, however, I am afraid this is not very realistic. If you want Cessna aerodynamicists to die from an heart attack, just show them this picture ^_^ In real life, and on most modern aircrafts, you do not have such protruding rivets unless you want your fuel consumption to go through the roof. Countersunk head rivets are used nowadays and their number and position are the result of a tough battle between the design office (who want a strong/cheap/light structure) and the aerodynamics office (who want very smooth/expensive air washed surfaces) ^_^ The result of these hard negotiations is that rivets *must have* a countersunk head (it is a minimum to enter a round of negotiation ^_^), there must be as few as possible of them, the gap between the rivet head and the countersunk hole should often be filled by a sealant (or at least by paint ^_^ both of them cracking in service anyway ^_^) and rivets with protruding heads are not an option (don't even think about them, unless you want to be crucified on the public place ^_^). The result, unfortunately, is not very spectacular as can be seen on the picture that Martin Spott sent a few days ago (http://foxtrot.mgras.net/bitmap/FGFS/DEEQA-Oelklappe.jpg) but it significantly improves your aircraft performance (and make the aerodynamicists happy - which is priceless). Cheers, Bertrand. P.S. No offence is meant to the aerodynamicists. They are very smart guys (you have to when you are involved in CFD) and most of them are really cool guys. Furthermore they are the greenest dept of an aircraft manufacturer since all their work is dedicated to the reduction of the fuel consumption ^_^ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal map shader example - c172p
2010/4/13 Stuart Buchanan stuar...@gmail.com: Bertrand wrote: This is some nice artistic/graphical work indeed, however, I am afraid this is not very realistic. If you want Cessna aerodynamicists to die from an heart attack, just show them this picture ^_^ :) I was basing the work on some photos I found on the Cessna website. This one in particular seemed to show raised rivets on the wing: http://www.cessna.com/MungoBlobs/832/502/sin_haw_flt18_hires.jpg Perhaps what I'm seeing there isn't actually protruding rivets at all. Is there any height change there at all, or are the surfaces completely smooth? I could obviously tone down the effect significantly to make them protrude less if that is more realistic. BTW - we're modeling a P model, if that makes any difference. -Stuart Well spotted Stuart. They look very much like protruding rivets. May be what I reported above is limited to some specific class of aircrafts ? A Cessna C172 is a relatively cheap aircraft flying at low speeds, may be this is why Cessna are using protruding rivets (which are cheaper than countersunk rivets). May be it only makes a difference at higher speeds ? It seems I have extrapolated my experience to an area where it does not apply ^_^ As you may have guessed I am not an aerodynamicist myself, moreover my own experience is limited to airliners where, I think, the criteria are more stringent than for small aircrafts... Or may be in Cessna the design office have won the battle against aerodynamics ? ^_^ Anyway my contribution was not much worth it... Next time I will check closer ^_^ Cheers, Bertrand. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS: source/src/Main bootstrap.cxx, 1.40, 1.41 fg_init.cxx, 1.239, 1.240 main.cxx, 1.301, 1.302 splash.cxx, 1.32, 1.33
Hi all,
I am bit taken aback by this commit. Is it really where the Flight
Gear community wants to go ?
As far as I understand the GPL, it is legal to rename an application
as long as the renamed application is still under GPL. So what is this
commit intended for ? Furthermore, do you honestly think that such a
simple trick has any chance to work ? And most importantly, under what
authority are we allowed to claim that a renamed copy of Flight Gear
is an Invalid version ?
FWIW I am the author of a few lines in the code of JSBSim and hence of
Flight Gear, and when I released my code under GPL, I really meant it.
If somebody tries to make money out of it then so be it, as long as
the software is sold under GPL. I am not doing that for a living but I
am all for enforcing Flight Pro Sim and the guys from eBay to release
their copies under GPL. However I will certainly not discourage them
from selling Flight Gear or whatever they call it in nice colourful
boxes.
IMHO this commit is pointless and I am concerned that it may be the
first step of many towards restriction of use.
Cheers,
Bertrand.
-- Forwarded message --
From: Durk Talsma d...@baron.flightgear.org
Date: 2009/10/24
Subject: [Flightgear-cvslogs] CVS: source/src/Main bootstrap.cxx,
1.40, 1.41 fg_init.cxx, 1.239, 1.240 main.cxx, 1.301, 1.302
splash.cxx, 1.32, 1.33
To: flightgear-cvsl...@lists.sourceforge.net
Update of /var/cvs/FlightGear-0.9/source/src/Main
In directory baron.flightgear.org:/tmp/cvs-serv29220/Main
Modified Files:
bootstrap.cxx fg_init.cxx main.cxx splash.cxx
Log Message:
Two patches:
1) Fix for the use custom scenery airport data property.
2) Make it a little harder for stupid people to make money behind our backs.
Index: bootstrap.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/bootstrap.cxx,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- bootstrap.cxx 10 Aug 2009 21:43:55 - 1.40
+++ bootstrap.cxx 24 Oct 2009 09:22:21 - 1.41
@@ -51,6 +51,7 @@
#include main.hxx
#include globals.hxx
+#include fg_props.hxx
#include fgviewer.hxx
@@ -249,10 +250,55 @@
return 0;
}
+void checkProgramIntegrity() {
+ int session = fgGetInt(/sim/session, 0);
+ string progName = fgGetString(/sim/startup/program-name, FlightGear);
+ char *checkname = new char[26];
+
+ checkname[2] = 116;
+ checkname[5] = 47;
+ checkname[1] = 116;
+ checkname[0] = 104;
+ checkname[21] = 46;
+ checkname[10] = 46;
+ checkname[15] = 104;
+ checkname[20] = 114;
+ checkname[23] = 114;
+ checkname[3] = 112;
+ checkname[12] = 108;
+ checkname[24] = 103;
+ checkname[16] = 116;
+ checkname[13] = 105;
+ checkname[4] = 58;
+ checkname[11] = 102;
+ checkname[19] = 97;
+ checkname[9] = 119;
+ checkname[8] = 119;
+ checkname[7] = 119;
+ checkname[6] = 47;
+ checkname[18] = 101;
+ checkname[14] = 103;
+ checkname[25] = 0;
+ checkname[17] = 103;
+ checkname[22] = 111;
+
+
+ if (session 100) {
+ if (progName != string(checkname)) {
+ cerr Invalid version: See checkname for
more information endl;
+#ifdef _MSC_VER
+ cerr Hit a key to continue... endl;
+ cin.get();
+#endif
+ }
+ }
+}
+
// do some clean up on exit. Specifically we want to call alutExit()
// which happens in the sound manager destructor.
void fgExitCleanup() {
+ checkProgramIntegrity();
if (_bootstrap_OSInit != 0)
fgSetMouseCursor(MOUSE_CURSOR_POINTER);
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.239
retrieving revision 1.240
diff -u -r1.239 -r1.240
--- fg_init.cxx 24 Oct 2009 08:31:40 - 1.239
+++ fg_init.cxx 24 Oct 2009 09:22:22 - 1.240
@@ -1440,6 +1440,7 @@
// = fgGetNode(/sim/presets/latitude-deg);
// static const SGPropertyNode *altitude
// = fgGetNode(/sim/presets/altitude-ft);
+
SG_LOG( SG_GENERAL, SG_INFO, Initialize Subsystems);
SG_LOG( SG_GENERAL, SG_INFO, == ==);
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/main.cxx,v
retrieving revision 1.301
retrieving revision 1.302
diff -u -r1.301 -r1.302
--- main.cxx 24 Oct 2009 08:31:41 - 1.301
+++ main.cxx 24 Oct 2009 09:22:22 - 1.302
@@ -770,7 +770,9 @@
fgGetInt(/sim/startup/ysize) );
fgSplashProgress(loading scenery objects);
-
+ int session = fgGetInt(/sim/session,0);
+ session++;
+ fgSetInt(/sim/session,session);
}
if ( idle_state == 1000 ) {
Index: splash.cxx
===
RCS file:
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS:
Let's say that I make a fork of Flight Gear by creating a new project My Flight Simulator under SourceForge, that I make a mirror copy of the Flight Gear CVS tree under my project and that the only commit I do is to change the name of the program. Then I release everything under the GPL. After a while (100 sessions) my (rare?) users will be surprised to see that My Flight Simulator is an Invalid version of Flight Gear which is obviously an illegal statement since : 1. My copy is perfectly compliant with the GPL 2. This statement is deliberately misleading which is illegal anyway in most countries. Hence Nicolas' statement. Cheers, Bertrand. 2009/10/24 Martin Spott martin.sp...@mgras.net: Nicolas Quijano wrote: I'm flabbergasted : disregarding the GPL to protect the GPL ? Ah ? Please specify, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS:
2009/10/24 Martin Spott martin.sp...@mgras.net: Bertrand Coconnier wrote: Your problem, since you're the one who distributes this piece of software. Nope see below. which is obviously an illegal statement since : 1. My copy is perfectly compliant with the GPL 2. This statement is deliberately misleading which is illegal anyway in most countries. Are you just about trying to add new features to the GPL ? Simply read the license text. I am not. You are. By claiming that any modification to the program name makes it an Invalid version you are implying that the right to modify the program name is limited. [...] TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION [...] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. I'm unable to find any section in the GPL that writing out 'misleading' statements is a violation of the license, [snip] Quote from GPL : 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further ^^^ restrictions on the recipients' exercise of the rights granted herein. ^^ You are not responsible for enforcing compliance by third parties to this License. As far as I can tell Invalid version means that it is not valid (am I patronising ?) which is a restriction on the user's right to modify the program name which, in its turn, is not allowed by GPL. Remove Invalid version and my claims will decrease from illegal to pointless/childish/naive whichever suits you best. Notice that the restriction that is implied by this commit also applies to any user who choose to modify the program name because let's say she wants to have several version of FlightGear on her PC and decides to modify FlightGear by FlightGear-1.9.2 or whatever. This is also in violation of the GPL. Not even mentioning that such users will be delighted... neither that deliberately distributing misleading statements is illegal - politicians, lobbyists, choose yout favourite ar doing this every day. I am happy to see that you accept that this commit will issue misleading statements, just as I am sure that you are not regarding mislead or deceit of Flight Gear users as acceptable means or collateral effects of enforcing Flight Pro Sim to comply with GPL. Don't get me wrong: I would not state that I really like Durk's move - in fact I personally didn't get to any final conclusion yet. I just think it's acceptable and, to be honest, I find it highly amusing how people are trying to attack Durk's move whithout having any substantive arguments at their hand Vanitas vanitatum et omnia vanitas... Cheers, Bertrand. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reverse for 737-300 model (patch)
Hi Gene, 2009/5/15 Gene Buckle ge...@deltasoft.com: The thrust reversers require that you go to idle power to engage them. However, after that you can run the power back up. This is a very interesting information. Thank you. In the real aircraft there is no indication that the reversers are on. I think it is quite not true. Deployment of the reverse must be controlled and monitored by the pilots since its inadvertent deployment can be catastrophic. See the crash of Lauda Air Flight 004 for an example. Or to be a bit less pessimistic if you command the deployment of the reverse during landing but only one reverser correctly deploys (the other one being jammed at mid-course of instance) then I think the pilots need to know that they will have asymmetric thrust if they pull the reverser thrust lever. So I can hardly believe there is no indication of the correct deployment of the T/Rs on the cockpit panel. Cheers, Bertrand. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reverse for 737-300 model (patch)
Hi Heiko, 2009/5/15 Heiko Schulz aeitsch...@yahoo.de: Hi, Some time ago, I started to improve the 737-300. I let it stall: no times, experiences I had with the development of the c172p and some personal things. I have still a copy on my local system but give up development There are some people which have my model, but what they do with it- no real idea. Hopefully the best. But I included also a reverse thrust so some thoughts and infos from me: Is it possible to have a copy of your model ? 1. The reverse can only be actuated while the engine is idle. I do not know if there is indeed a system which prevents that in the real 737. But I don't think this can be done anyway with engines running at full or intermediate power because the actuators won't have enough power to overstow the pressurised cowl in order to disengage the locks. No idea if there is a lock in the real thing, but sounds very reasonable! I have no clear idea either but I cannot believe that the actuators are pulling the cowl during all the flight to prevent the reverser from opening. There must be a system to prevent the hydraulics to be stressed during all the flight and the most obvious is locks. 2. I have added some drag when the reverse is deployed. Indeed on some airlines, when the weather conditions allow it, the pilots use the reverse as a mere speedbrake: they deploy the reverse when landing and leave the engines idling. This is to save fuel and engine wear. The drag that I have included in the model allows to reproduce such a procedure. No need to say that the value 0.018 in the formula is just a guess so that the drag of the reverse is in the neighbourhood of the gears drag. If you modelled a real reverse, there is no need for adding a drag imho. This is an interesting remark and I did not think about that. I have made some further investigations and my conclusions are : The reversed thrust when the T/R is operated is the addition of two forces: 1. The ram drag of the engine itself which is basically equal to the airflow multiplied by the aircraft speed 2. A portion of the airflow which is indeed ejected forward and produces in reaction a backward thrust. The first component is obviously proportional to the airspeed while the second one is proportional to the thrust. So my initial proposal was obviously wrong since it used qbar which is proportional to the square of the airspeed. On the other hand, if you look at the thrust table of Engines/CFM56.xml you will see that the idle thrust is more or less constant over the speed range of a landing airplane (i.e. 0Mach0.2). So your suggestion only includes the second component and does not reproduce the reality either. However the current turbine model of the engine does not compute the airflow or the ram drag of the engine so I will stick with your idea until I can do something better. I used propertyfdm/jsbsim/propulsion/engine[1]/reverser-angle-rad/property value180/value as solution for reverse thrust. Works, and you have a slight drag with engine in idle. Oddly the value 180 suggests that you entered the angle in degrees while it should be entered in radians (which means that you have entered an angle of 180 mod 2*pi = 4,071 rad = 233.24 deg). With such a value the reversed thrust is almost 60% of the forward thrust. After some investigations, the performance of most thrust reversers is in the area of 40%. Hence an angle of acos(-0.4) = 1.98231 rad = 113.58 deg should be reasonably close to reality. Yes I know, my first guess was not this value... :-/ A improved 737 would be still great- fine to see that someone is working on that! Regards HHS The 737 (Classic) was one of my favourite airplanes on MS Flight Sim (booh shame on me). Hence my interest on it. Cheers, Bertrand. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reverse for 737-300 model (patch)
Or may be the indication is only available on the more modern aircrafts ? 2009/5/17 Bertrand Coconnier bcoco...@gmail.com: Hi Gene, 2009/5/15 Gene Buckle ge...@deltasoft.com: The thrust reversers require that you go to idle power to engage them. However, after that you can run the power back up. This is a very interesting information. Thank you. In the real aircraft there is no indication that the reversers are on. I think it is quite not true. Deployment of the reverse must be controlled and monitored by the pilots since its inadvertent deployment can be catastrophic. See the crash of Lauda Air Flight 004 for an example. Or to be a bit less pessimistic if you command the deployment of the reverse during landing but only one reverser correctly deploys (the other one being jammed at mid-course of instance) then I think the pilots need to know that they will have asymmetric thrust if they pull the reverser thrust lever. So I can hardly believe there is no indication of the correct deployment of the T/Rs on the cockpit panel. Cheers, Bertrand. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Reverse for 737-300 model (patch)
Hi all, Not sure it is the right mailing list to post this but I have made a patch to activate the reverse on the 737-300 of FlightGear. I have seen on FG Wiki that David Culp and Innis Cunningham are the authors of the 737 model so I have put Dave on copy of this e-mail. However I do not know Innis' e-mail address hence this post. Basically, this patch activates the reverse functionality for the 737. It is based on code from other airliners of FG with the same key binding (Delete) and the relevant animation (fortunately the 3D model allows this animation without any modification). However there are some small specificities in my patch: 1. The reverse can only be actuated while the engine is idle. I do not know if there is indeed a system which prevents that in the real 737. But I don't think this can be done anyway with engines running at full or intermediate power because the actuators won't have enough power to overstow the pressurised cowl in order to disengage the locks. 2. I have added some drag when the reverse is deployed. Indeed on some airlines, when the weather conditions allow it, the pilots use the reverse as a mere speedbrake: they deploy the reverse when landing and leave the engines idling. This is to save fuel and engine wear. The drag that I have included in the model allows to reproduce such a procedure. No need to say that the value 0.018 in the formula is just a guess so that the drag of the reverse is in the neighbourhood of the gears drag. I did not find any indicator of reverse deployment on the cockpit panel (even when scrolling the panel with SHIFT+F7/8). So I guess that it needs to be added. I will search the internet but if anybody has any information/picture regarding that I will be more than happy to use them. I am a poor 3D modeler so I cannot update the model myself. But for those who can and are interested in: there are several subtle errors on the model regarding the deployment of the reverse. 1. The Inner Fixed Structure (IFS) should be masked by the grids of the reverser (see http://www.airliners.net/photo/Scandinavian-Airlines--/Boeing-737-683/1214710/L/sid=b5f6ee391864d2b58be0ef928940e316 ) 2. The 12 o'c and 6 o'c bifurcations are missing on the IFS. However I am not sure this is relevant if the grids are added to the model. If the authors are happy with this patch then I plan to add some details to it. The first one will be cockpit indication and the second one reverser inhibition. FAA allows the 737 to be used with one reverser inhibited. I think it can be a small challenge to land with only one reverser (and compensate the moment with the rudder). Any comment / suggestion please let me know. Cheers, Bertrand. Index: 737-300-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737-300/737-300-set.xml,v retrieving revision 1.4 diff -u -r1.4 737-300-set.xml --- 737-300-set.xml 22 Feb 2009 21:02:22 - 1.4 +++ 737-300-set.xml 15 May 2009 14:17:29 - @@ -51,8 +57,7 @@ view n=1 config !-- big plane, so extend chase view offset a bit -- -z-offset-m type=double - archive=y-80.0/z-offset-m +z-offset-m type=double archive=y-80.0/z-offset-m /config /view @@ -106,6 +121,13 @@ /default /menubar + help + titleBoeing 737-300/title + key +nameDelete/name +descToggle thrust reversers/desc + /key + /help /sim consumables @@ -146,6 +168,9 @@ fileAircraft/737-300/Systems/air-ground.nas/file fileAircraft/737-300/Nasal/liveries.nas/file /airground + reversethrust + fileAircraft/737-300/Nasal/reverse-thrust.nas/file + /reversethrust /nasal instrumentation @@ -184,6 +209,18 @@ /params /environment + input + keyboard + key n=127 +nameDelete/name +descToggle Reversers/desc +binding commandnasal/command + scriptreversethrust.togglereverser()/script +/binding + /key + /keyboard + /input + /PropertyList Index: 737.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737-300/737.xml,v retrieving revision 1.4 diff -u -r1.4 737.xml --- 737.xml 26 Jan 2009 20:37:19 - 1.4 +++ 737.xml 15 May 2009 14:17:30 - @@ -677,6 +686,16 @@ /product /function +function name=aero/coefficient/CDrv +descriptionDrag_due_to_reverse/description +product +propertyaero/qbar-psf/property +propertymetrics/Sw-sqft/property +property/engines/engine/reverser-pos-norm/property +value0.018/value +/product +/function + /axis axis name=SIDE Index: Models/737-300.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737-300/Models/737-300.xml,v retrieving revision
