As I had reported on 2004/8/4 00:02:56 ("yasim + bo105 + vrp + @#%$#@ == argh!"),
there must be a bug somewhere in YASim, which is responsible for the Bo105
turning around the FDM origin (nose tip) rather than the CG. Some people assumed
that I was just another victim of the "view offset" illusion, but this wasn't
and isn't the case.
    Maik Justus (the rotor man) has now supposedly found the bug in YASim[1].
Look at this code in FDM/YASim/Integrator.cpp:35--66:



// Transforms a "local" vector to a "global" vector (not coordinate!)
// using the specified orientation.
void Integrator::l2gVector(float* orient, float* v, float* out)
{
    Math::tmul33(_s.orient, v, out);
}

// Updates a position vector for a body c.g. motion with velocity v
// over time dt, from orientation o0 to o1.  Because the position
// references the local coordinate origin, but the velocity is that of
// the c.g., this gets a bit complicated.
void Integrator::extrapolatePosition(double* pos, float* v, float dt,
                                     float* o1, float* o2)
{
    // Remember that it's the c.g. that's moving, so account for
    // changes in orientation.  The motion of the coordinate
    // frame will be l2gOLD(cg) + deltaCG - l2gNEW(cg)
    float cg[3], tmp[3];

    _body->getCG(cg);
    l2gVector(o1, cg, cg);    // cg = l2gOLD(cg) ("cg0")
    Math::set3(v, tmp);       // tmp = vel
    Math::mul3(dt, tmp, tmp); //     = vel*dt ("deltaCG")
    Math::add3(cg, tmp, tmp); //     = cg0 + deltaCG
    _body->getCG(cg);
    l2gVector(o2, cg, cg);    // cg = l2gNEW(cg) ("cg1")
    Math::sub3(tmp, cg, tmp); // tmp = cg0 + deltaCG - cg1

    pos[0] += tmp[0];         // p1 = p0 + (cg0+deltaCG-cg1)
    pos[1] += tmp[1];         //  (positions are doubles, so we
    pos[2] += tmp[2];         //   can't use Math::add3)
}



As you can see, Integrator::l2gVector() does not access its parameter
orient, but the object variable _s.orient! This could still be
intentional and left over from a prior version (although the parameter
should clearly get removed then).
   But then, Integrator::extrapolatePosition() calls l2gVector()
twice, once with o1 and once with o2. As we know, these are ignored
in l2gVector() anyway!

Andy says that the code is correct. But why are then three parameters
ignored, and the comment praises the interpolation between two positions,
while the code does something different? And why does changing _s.orient to
orient actually fix the "incorrect rotation" bug?

Now, is it a bug? Or just unused parameters and inconsistent comments?

m.






The suggested (but according to Andy wrong) fix:   (Please do not apply!)


RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/YASim/Integrator.cpp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Integrator.cpp
--- Integrator.cpp      10 Sep 2002 01:14:03 -0000      1.1.1.1
+++ Integrator.cpp      7 Oct 2004 16:50:36 -0000
@@ -36,7 +36,7 @@ State* Integrator::getState()
 // using the specified orientation.
 void Integrator::l2gVector(float* orient, float* v, float* out)
 {
-    Math::tmul33(_s.orient, v, out);
+    Math::tmul33(orient, v, out);
 }

 // Updates a position vector for a body c.g. motion with velocity v





[1] Maik's analysis (bad translation):
I assume a bug in void Integrator::l2gVector(float *orient....) in integrator.cpp,
which does only contain one function call: Math::tmul33(_s.orient,....).
Not the orientation function parameter is accessed here, but the one of the current
state, which doesn't change between the two calls of this function, though.
Thus, the rotation around the CG (which includes a translation in the other
coordinate system) isn't applied correctly. Changing the function call to
Math::tmul33(orient,.... should fix the problem.



_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to