Re: [Jsbsim-devel] Reverted changes

[Agostino De M. <ago...@un...>]

Bertrand,
I'm so glad of these code refinements. Especially
regarding the <orientation> tag. You're really doing
a good job. Thanks.

Agostino


Bertrand Coconnier <bco...@gm...> ha scritto:

> 2012/3/25 Jon S. Berndt <jon...@co...>:
>>> * FGLGear : Simplified the conversion from the structural frame to the
>>> body frame. Reordered the ground frame axes in a more conventional
>>> sequence.
>>
>> I like the way this sounds, but would like to take a look at the changes
>> before committing them. That's what Codestriker
>> (https://sourceforge.net/apps/codestriker/jsbsim/codestriker.pl) is useful
>> for. You might take a look at it. Otherwise, maybe a description in the list
>> would be OK.
>>
>
> It seems I am not allowed to use the function 'create new topic' in
> Codestriker. SourceForge complains that 'This function requires admin
> access.' So I am re-submitting this change the old way i.e. as a diff
> file to the ML
>
> This patch is a slightly modified version of the changes I committed
> (and reverted) last week.
>
>    ******
>
> 1. The patch removes the std::vector vWhlBodyVec from the structure  
> FGLGear::in.
>
> Currently the gear positions are stored in structural frame
> coordinates. Following the effort that has been conducted several
> months ago to reduce the dependencies between the Models, the
> conversion from the structural frame to the body frame currently takes
> place in FGFDMExec.cpp which calls FGMassBalance::StructuralToBody().
> As a consequence, the result of this conversion needs to be stored in
> an std::vector.
>
> Now, the conversion from the structural frame to the body frame is
> really simple : it consists in changing the origin of the frame and
> pivoting the axes by 180deg around Y (and converting from inches to
> feet). This conversion can therefore be done in FGLGear provided that
> the class knows the CG location in the structural frame.
>
> The attached patch therefore removes the std::vector and copies the CG
> location to FGLGear when FGFDMExec::LoadInputs() is executed. The
> conversion from structural to body is then done in the FGLGear class.
>
>    ******
>
> 2. The code that computes the orientation matrix of a gear is simplified
>
> By default, JSBSim assumes that a landing gear strut is parallel to
> the Z axis of the body frame. An option is provided where the strut
> can have a different orientation. This is obtained by using the
> <orientation> tag in the definition of a gear.
>
> Previously, the transformation matrix from the landing gear
> orientation to the body frame was computed by classical trigonometry
> based on the Euler angles provided by the <orientation> tag.
>
> The attached patch does the same thing by using the FGQuaternion class
> that already contains all the math to build a matrix from the Euler
> angles. Since the calculations are carried out only once during the
> class initialization, the overhead resulting from creating a temporary
> quaternion and calling its methods is negligible.
>
>    ******
>
> 3. The ground frame axes are reordered in a more conventional sequence
>
> FGLGear computes a ground frame at each iteration to assess the
> direction of the normal reaction to the ground as well the rolling and
> slipping directions.
>
> Currently, the ground reaction force is computed in this ground frame
> and transformed to the body frame by using the inheritance of FGLGear
> from FGForce. The transformation matrix is a private member of
> FGForce, hence FGLGear has no direct access to it. It had to tweak the
> Euler angles of FGForce stored in FGForce::vOrient and to call
> FGForce::UpdateCustomTransformMatrix(). This resulted in (1) a quite
> complex code in FGLGear::ComputeGroundCoordSys and in (2) an
> unconventional axes sequence.
>
> Changing the transformation matrix 'mT' in FGForce from 'private' to
> 'protected' allows a direct access of FGLGear to the transformation
> matrix. This allows to directly computes the 9 components of the
> transformation matrix. It also allows to reorder the ground frame axes
> in the following order :
>
>   eX : projection of the rolling direction on the ground
>   eY : projection of the slipping direction on the ground
>   eZ : normal to the ground
>
> This is a more conventional order (X points to the fwd direction, Z
> points upward). Direct calculations make the code easier to
> understand.
>
>    ******
>
> 4. Minor code changes
>
> Most of them are the result of the ground frame axes reordering.
>
>    ******
>
> Comments are welcome.
>
> Bertrand.
>



-------------------------------------------------------
Agostino De Marco, PhD
Assistant Professor
Università degli Studi di Napoli Federico II
/ University of Naples Federico II /
Dipartimento di Ingegneria Aerospaziale
/ Department of Aerospace Engineering /
via Claudio 21, 80125 Napoli - Italy
Tel.: +39 0817683323
Fax:  +39 0817683622
Email: ago...@un...
Web 1: www.dias.unina.it/adag
Web 2: www.eolpowergroup.com
-------------------------------------------------------