Re: [Flightgear-devel] JSBSim bug fix that should be backported to FG 2.8.0

[jonsberndt]

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 
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 
:
> 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

[jonsberndt]

> 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] "proper" ground reactions (was "YASim & sliding helicopters bug")

[jonsberndt]

> 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

Re: [Flightgear-devel] YASim & sliding helicopters bug

[jonsberndt]

> 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 abou