Re: [Flightgear-devel] [Flightgear-commitlogs] [FlightGear] 02/02: YASim gear: Clamping of _frac replaced

[Julian S. <ju...@op...>]

On Thu, 20 Jul 2023 14:30:22 +0100
James Turner <ja...@fl...> wrote:

> > On 7 Jul 2023, at 22:10, Julian Smith <ju...@op...> wrote:
> > 
> > But against that is the fundamental unreality of the new algorithm - it
> > attempts to define behaviour for when the gear is compressed beyond its
> > real-life breaking point.
> > 
> > Hence my preference that if we are to include the algorithm, there
> > should be a way to turn it off.  
> 
> I have a bit of workflow anxiety here: I agree we need to revert for the moment, because we have issues with even our default airport. But I worry that once it’s reverted we are back to basically zero with making progress on the underlying issues Jakub was attempting to solve. (And that’s quite a de-motivating situation for any contributor)

Understood about potentially de-motivation. But we did apply the patch.
And hopefully the various discussions about this issue indicate that
it's being treated seriously.

> 
> Arguably we are slightly improved, in that we now know that our scenery / ground-reaction code is partly to blame, since it generates glitchy data. (I am guessing we have some very thin cracks in the scenery, since I don’t imagine we have a 10km spike in the middle of BIKF). Interesting question for me would be, if the scenery returned plausible (filtered?) values, would the original patch still be necessary? (Ie how many different problems are we fixing here?)
> 
> I would be happy if someone can try to the ‘increasing the spring fraction as compression approaches 1.0’ alternative which you (Jules) proposed, to see if it’s any better. I’m also wondering if we could construct a unit-test for Gear.cpp which runs calcForces with some different test-data (and mock ground plane of course), so that we could work on the behaviours here in a more deterministic way.

For reference, this all started with
https://sourceforge.net/p/flightgear/codetickets/1509/.

It's a bit curious because the original reproducer says:

    reduce spring constant so, when plane is stationary, nose gear
    reaches full compression.

It's hardly surprising that things go wrong if one deliberately
mis-configures things like this, so this on its own would not be a
reason to change anything, IMHO.

However a later comment says:

    But I tested the my above linked merge request at TF-G2 model,
    where light spring constants are needed to be able to land on a
    grass.

So i think this is suggesting some particular aircraft may need a
modified spring function that gives greater force than normal when
highly compressed. (I wonder whether there's any information on the
real aircraft having such non-linear suspension?)

But we've recently learned that we must not allow ridiculously high
compression to cause ridiculously high spring forces, because the
ground level can momentarily leap upwards by thousands of metres.

Any simple spring functions will tend towards infinitely as _frac
increases well beyond 1.0. So we'll need to limit _frac to some maximum
value. I think we should use the original limit of 1.0 because that
matches real life, where maximum possible gear force corresponds to
maximum possible gear deflection.

The remaining issue is what non-linear spring function should we use?
The current one is basically:

    force = _spring * compression * _frac

Where `compression` is the maximum compression distance specified in
the XML. `_spring` is the XML's dimensionless `spring` value multiplied
by an auto-generated default spring constant, which depends on the
aircraft mass, approach speed etc etc.

Maybe we could simply add a quadratic term scaled by a new
dimensionless constant `spring2` in the XML:

    force = _spring * compression * (_frac + spring2 * _frac**2)

[One could view `spring2` has modifying the maximum force of the
spring at full compression, 

    force_max -> force_max * (1 + spring2).

For example `spring2=10` would result in 11x the force at maximum
compression compared to the default `spring2=0`.]

I'm hopeful that this could address the original problem without the
danger of pathological behaviour. I think it would be pretty easy to
implement too.


In summary:

* The default value for spring2 would be zero, so this will not effect
  the behaviour of existing aircraft.

* None-zero values of `spring2` should address the original problem for
  those aircraft that need it.

* The suggested quadratic function, and preserving the clipping of
  _frac to 1.0, will ensure that pathological scenery doesn't crash
  things.


- Jules

-- 
http://op59.net