Re: [Flightgear-devel] JSBSim bug fix that should be backported to FG 2.8.0
Actually, I may have an additional fix that needs to be applied, but may not be able to confirm it until Monday or Tuesday. Jon Original Message - From: Arnt Karlsen lt;a...@c2i.netgt; To: flightgear-devel@lists.sourceforge.net Sent: Fri, 20 Jul 2012 13:05:13 - (UTC) Subject: Re: [Flightgear-devel] JSBSim bug fix that should be backported to FG 2.8.0 On Fri, 20 Jul 2012 11:10:47 +0200 (CEST), Anders wrote in message pine.lnx.4.64.1207201107240.4...@sleipner.gidenstam.se: On Thu, 19 Jul 2012, Bertrand Coconnier wrote: 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. Given that there is some risk that the behaviour of carefully tuned flight models change I'd suggest we only update 2.9.0 and do not update 2.8.0 as it is late in its release cycle. ..an idea: Fix both and the aircraft FDMs that comes with 2.8.0, and set up a warning on the not-yet-fixed FDMs? Or maybe set up a Fixed flag in those that are fixed? Warnings can be extended to invite users to send bug nag reports to flog in bug fixes. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmosphere
From: Torsten Dreyer Loosing the ability to control the atmosphere within FlightGear would be a massive loss of functionality. We currently control atmosphere in several different ways like real weather based on METAR. The local weather project has just started to create a complex weather simulation system and I am (slowly but steadily) working on adding more live weather data, including aloft wind, temp and dewpoint for any point of this world. It would be a huge degression to be able to fly within ICAO standard atmosphere, only. Torsten I should have worded this better, because it's not my intention to propose removing functionality with FlightGear. What I mean to ask is what is the current (and planned) way that FlightGear interacts with atmosphere modeling (not referring to winds, at the moment)? The JSBSim standard atmosphere models the U.S. Standard Atmosphere, and supports user-supplied adjustments to the temperature. In the FlightGear/JSBSim interface there is an allowance made to drive the atmosphere model by setting temperature, pressure, and density. At this point (with FlightGear driving STP), any calculations done by the JSBSim standard atmosphere model because superfluous. In the case where FlightGear is to drive the atmosphere model for JSBSim aircraft, there should be what amounts to a null atmosphere model that only provides the C++ interface to storage and common atmosphere calculations (viscosity calcs, for instance). Trying to make the JSBSim standard atmosphere model serve both purposes has resulted in code that is convoluted and difficult to read, and error prone. So, the question that remains is to consider how to provide the capabilities that both parts need. I'm beginning to think that FlightGear should provide its own atmosphere model, and then just copy values into a null JSBSim atmosphere model when integrated with FlightGear, or be happy with the JSBSim implementation of the standard atmosphere with temperature and pressure offsets. Winds and turbulence are another matter. We have a couple of turbulence models and the recently added Milstd and Tustin wind models are looking pretty good. In a discussion on the JSBSim developer list, I proposed separating out the wind model and the atmosphere model. It's all open for discussion ... JB -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug
If this is truly the case, and if it is due to a gear modeling fidelity issue, then I agree. But, the kind of problem you describe would be a different issue. Since wind effects are only ramped in as velocity increases, the example you describe above should not happen with JSBSim. I just put the default Cessna at EDLN RWY 13 with parking brake applied, the wind is 11009KT. It took approx. three and a half minutes to let the aircraft slip backwards by the length of a main gear cover. Exactly. Given what was happening prior to the fix, this is pretty good. I think with some additional tweaking, this could be improved even more. But, I'm not sure what your point is, here? We should probably specify some requirements. How long should an aircraft stick at one spott? With what kind of tolerance? There is a long, huge, list of items that could be included in landing gear modeling and ground reactions. Anything from tire spin-up/wind-up to castering jitter, strut dynamics, etc. Obviously, we have to make some decisions about how far we want to go in modeling this or that feature. To this point, the focus has been on stability and control, aerodynamics, and such. I'm not opposed to improving the landing gear model. But, I'm not certain I hav e a good feel for how big of an annoyance this is among the larger user base. Consider this a solicitation for input! :-) My proposal is either to develop a copy of the FDM inside FlightGear and to focus primarily on FlightGear's needs (and to try getting a copy of the respective patch) or to have the changes applied to JSBSim's code tree and to later merge this into FlightGear. I don't think having a copy of JSBSim in FlightGear CVS for development purposes is a good idea. I do like the idea of more frequent synchs between JSBSim CVS and FlightGear CVS. But, JSBSim is used on a broader scale than FlightGear (OpenEaagles, for one, and many more ). I think that is a strength - not a weakness. I don't think it would be a good idea to split it up. You may not be aware of this, but the patch previously submitted years ago would not work at all any more. In fact, one of the problems with the patch was that even at that time, JSBSim was undergoing a restructuring. That made it especially difficult for the patch author. In order for the same approach to be applied at this time, one would have to essentially start over. Some of the parts might be applicable and usable, but I believe much of it would have to be rewritten. But, forget about the patch as it was. Even if we wanted to, there's no way it could be applied as-is, at this point. Also, your characterization of the lack of willingness to commit the changes as being due to a concern about line count is incorrect. That's a gross over-simplification, and implies a lack of concern or care about the work that I know went into creating the patch. Obviously, at some point, one has to weigh the amount of code added to address a specific problem. Is doubling the size of the codebase to address a single problem acceptable? Think of the implications for maintenance, comprehension, and documentation. There is a saying that the squeaky wheel gets the grease (although in this case maybe we need less grease!). If we could improve the gear model by adding two lines of code, I would have added that code years ago. If any fix doubles the size of the codebase, no, I'd be looking for a better way to address the problem. With anything in-between, it gets vague, and the rules become less strict. Let me say this, in closing. I've worked with some very heavy duty simulations over the past twenty+ years. Most (all?) of them are horribly incomprehensible for even experienced simulation engineers, let alone students. JSBSim has been complimented in the past because it is straightforward and fairly easy to understand the code, at least as far as the basic stuff goes. Some design choices have been made so far that not everyone agrees with. One of those areas is that landing gear is modeled only with enough fidelity to make it appear to users that the aircraft drives in a realistic manner. Where that is not the case, I need to see specific examples so we can address that. If we can address it with a small amount of code as is currently the case, that's an acceptable solution, in my eyes. If it turns out that we really cannot address any problems without a more serious solution, and the ground reactions are seen as plain-and-simple not plausible, and there is a huge outcry that this should be fixed because it is intolerable, then maybe we'd revisit a modification to our integation scheme to use RK4 and simultaneous solution of a set of equations. That would involve a long and painful surgery, though. It's not an easy thing to manage such a project, with some competing interests, and to keep users and developers happy and feeling good about their contributions
Re: [Flightgear-devel] proper ground reactions (was YASim sliding helicopters bug)
Where is the proper gear model patch, Martin? mail.flightgear.org is down so the archives prior to 2005 are unreachable. I'm interested in taking a look. I'm also wondering what is stopping you from grabbing a copy of JSBSim, applying the patch, and providing some data to the powers that be to validate this proper ground reaction model? If it's as simple as applying a patch, why not spend some time/effort making your case with data rather than simply tossing emails back and forth? Just a thought. == I think what Martin is referring to can be found here: == http://developer.berlios.de/projects/openfdm/ == Greetings, Torsten No, that's not it. Actually, there is no patch, per se. There is a branch in JSBSim cvs from several years ago that contains a set of files, some new, some modified. Since that time, the main branch of JSBSim has evolved and grown very considerably. Jon -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
