[Orekit Developers] Attitude class : conventions, problems, solutions and improvements

[Anxionnat Julien <Julien.Anxionnat@cnes.fr>]

Hello,

I'm working for the CNES, where I'm in charge of the attitudes and kinematics subjects for the Sirius project. (I'm a co-worker of Yannick Tanguy who appears regularly on this mailing-list.) So, I'm gonna speak about attitude, rotations and quaternions, cause we encounter several problems...


I'm sure this subject has provoked numerous discussions, but it's a pretty hard problem for us. All our kinematic and guidance algorithms are based on the most-used international convention :
"The rotation r where theta is the angle of the rotation and u the axis of the rotation is represented by the quaternion Q = ( cos(theta/2) , sin(theta/2).u )."
Accordingly, we have v' = q.v.q* where v' yields the vector v rotated by the angle theta aroud the axis u.
Badly it's not the convention in Commons Math. Okay, we have to compose with it.
(For information, we discussed with CM community few months ago to create a Quaternion class in CM and to modify the constructors and the getters of the Rotation class to manage the two conventions : "CCSDS" (above) and "Classical" (the "original"). If desired, I could attach our code of this modified Rotation class.)

I guess that's the reason why the rotation representing the attitude in Orekit is also the inverse of the most-used convention : all references and recommandations give the attitude as the representation of the orientation of the satellite frame relative to the reference frame. And it turns out that the Orekit getRotation() returns the rotation from the sat frame to the ref frame...
With a getQx(), admittedly the quaternion is "good conventioned", but it isn't pretty clean. In this state, we cannot reuse this package for our guidance applications.


So we have a proposition to improve the actual attitudes package (adding some kinematic and guidance algorithms) and also to clarify the direction of the rotation (and make it more user-friendly) :

1. Creation of "KinematicElements" class with attributes :
- attitude : Rotation [= rotation from R to S = rotation which transforms the axis of R frame into the axis of the S frame]
- spin : Vector3D [= angular velocity of S relative to R, expressed in S]
- acceleration : Vector3D
- jerk : Vector3D
- snap : Vector3D
=> It's the user (or the using class) of these elements who manage the concerned frames.
The jerk is the derivative of the angular acceleration, and the snap the derivative of the jerk. These derivation orders are needed by our kinematic algorithms. Of course, they'll be optional.

2. Changes in Attitude class :
- turning getRotation() to @deprecated,
- creating getRotationSatFrameToRefFrame() to substitute it,
- turning getSpin() to @deprecated,
- suppressing the attitude and spin attributes,
- creating the attribute kinematic of type KinematicElements (which represents the kinematic of sat frame relative to the ref frame),
- creating the getters getKinematicElements() and getKinematicElements(order : int).

What do you think about that ?


Best regards,
Julien Anxionnat