> 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 and attempts at improvements. I appreciate this dialogue, and
your input. I know that you may not agree with the reasoning behind past
decisions, but I hope you can at least see that they were made carefully and
for reasons that I sincerely thought were for the overall good of the project.
I'll also add that in my view the door is not closed for future changes.
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
