Maik Justus wrote:
> my impression was, that a stab is not producing forces perpendicular to
> its surface, when the wind is blowing perpendicular to its surface
You have misinterpreted the code, I think. The "stallLift" value is
only one contribution to the transverse force from the surface.
Regular "drag" forces still apply, and I assure you they work. If
they did not, YASim aircraft would not be stable when placed in
zero-velocity situations like a hammerhead stall or similar situation
where AoA goes through 90.
> The fuselage is simulated as a open tube and in the bo the resulting
> drag was to small I think. Therefore I added a vertical stab to
> close the tube at the beginning. This vertical slab I realized by an
> stab with 90 deg. incidence. There should be many other ways to do
> this without a vertical stab, but this way was self-evident for me.
OK, I understand. But this is a hack. Your problem has nothing to do
with surface incidence: your problem is that the fuselage drag is too
low. Since the solver isn't run for helicopters, that isn't
surprising. Why not investigate solutions that address the actual
problem* and don't involve putting trig operations into the inner loop
of the simulator?
If you *really* need this feature and don't want to use one of the
IMHO more general features above, can you provide it to me as a
separate patch with change comments? It really isn't related to
helicopters.
The performance cost here is rather high, this code gets hit at 400 Hz
for every surface in the aircraft (and there can be hundreds on a big
plane). The small angle trick was being used for a reason, basically.
* Suggestion A: an "effectiveness" parameter for fuselage tags that
works like it does for wings, so you can tune it per-aircraft.
Suggestion B: a new "spheroid" type that creates surfaces
distributed in 3D around a center point instead of the 1D
distribution you get from a fuselage tag. This would probably
still need an effectiveness tunable, but will be much easier for
authors of helicopters and airships to use than vstab objects.
> Andy Ross wrote:
> > The boundary changes in Wing.cpp don't make any sense to me.
>
> Therefore for an wing without flap, spoiler and slat [...] no surface
> element is generated.
Ah, OK. Yes, this was indeed a bug; I'm kinda shocked that we never
noticed this before, it's been there since the code was written. And
unfortunately it affects *all* wings with segments that like between a
control position and an edge. Which means that we're going to need to
retest the solution results for basically every YASim aircraft once
this goes in. Ick. :(
As always, it's nicer to hear about bugs as bug reports, and not as
anonymous changes in a 120k patch file. :) Can you (1) split this out
into a separate patch as above, (2) add a comment explaining the two
new entries in the table, and (3) write "10" instead of "8+2" (or
BOUND_COUNT or sizeof(bounds)/sizeof(bounds[0]), etc...).
> Yes, I will change this. The lines [...] will be replaced by one
> function call.
OK. But why must this be in Model.cpp? That class is a top-level
wrapper that contains a bunch of sub-objects to do the real
simulation; it doesn't have any aircraft-specific logic. Shouldn't
this be part of a Rotor? If not, maybe you need another abstraction?
(RotorShaft, maybe, by analogy to PropEngine?)
The immediate complaint was that this was a lot of very
special-purpose code inside my a small, general function. But the
proximate issue remains: this seems like a lot of special-purpose code
without an obvious "home" in the design. Abstraction is nice: it lets
your changes go into files that you "own" (like Rotor*.?pp) without
being torn apart by viscious folk like me. :)
> Of course I didn't want to change your comment. Yes, there is some
> integration done [...] the compensation of the rotation of the
> fuselage. The rotor does not follow the rotation of the
> fuselage. Therefore its rotation must be subtracted from the
> orientation of the rotor. I think, one could call this "unstiff
> problems".
Leaving a comment in place above your code that you disagree with
seems kinda silly; I don't care if I wrote it or not. Pull it out and
replace it with the above explanation of why this code is OK inside of
initIteration() and does not need to be in calcForces().
A more general suggestion: isn't this a design bug with your choice of
coordinates? The body is an accelerated reference frame. Wouldn't it
be better to store the rotor orientation as a matrix in the global
frame instead, the same way aircraft orientations are stored? Not
only would you be able to skip this step, you would be immune to
physics bugs caused by rapid rotations of the helicopter body.
> For debugging the rotor code I had switched the floating point
> exceptions on. But I got floating point exceptions exactly in the
> modified functions directly after starting the program, probably due
> to uninitialized variables somewhere else.
OK, then we need to fix *those* bugs (which, as above, will never
happen if you don't report them!). Your patch only hides them, and it
does so incorrectly. If you don't want to track the original issue
down, then better fixes would be:
A. A zero _totalMass (which should *never* happen, and really should
be a fatal error if you were seeing it) can be approximated as a
suitably small number as long as you know the units
involved(e.g. 1.0e-06 kg will work fine without hitting any
truncation issues in single precision math). Setting it to 1.0 is
just weird.
B. A identically zero _spin vector (which, OK, is actually something
that might happen in principle) should be replaced with a nominal
unit vector like [0,0,1] or the like. Your code actually isn't
technically incorrect (the resulting zero-length vector only gets
used in a dot product, which is safe) but is definitely confusing.
This issue is a pet peeve of mine. As a general rule, floating point
code should never be testing a number for equality. Doing so leads to
just this kind of discontinuity: the behavior of the simulator is very
different at one value than at one infinitesimally close.
> > There are several spots where you have commented code out instead
> > of removing it
>
> I hope I only did this where I modified your code to illustrate the
> changes.
This is another pet peeve: the right way to illustrate changes is to
use a patch file and accompanying change comments (you gave me the
former, but not the latter). Commenting stuff out just guarantees
that you will confuse someone later on ("what happens if I uncomment
this?"). Just don't do it, code can only be maintained when it is
*code*, not comments.
Andy
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
