Re: [Orekit Users] Reference frame of a S/Cs attitude

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Raffaello.Lorenzo.Mancini@esa.int a écrit :

> Dear list members,

Hi Raffaello,

> I'm in the course of developing a simple application using Orekit to
> calculate the time series of the following paramters for a satellite link
> to an earth ground station:
>
> 1. slant range
> 2. elevation (as seen from G/S)
> 3. S/C-G/S-Sun angle
> 4. two offset angles between an antenna on the S/C and the line of sight
> to the G/S.
>
> Currently I am able to produce parameters 1 and 2 using the following
> code:
>
> SpacecraftState currentState = propagator.propagate(now);
> PVCoordinates topoScPv = currentState.getPVCoordinates(gsTopoFrame); //
> gsTopoFrame is the topocentric frame of the G/S on earth
>
> double slantRange = gsTopoFrame.getRange(topoScPv.getPosition(),
> gsTopoFrame, now);
> double elevation = gsTopoFrame.getElevation(topoScPv.getPosition(),
> gsTopoFrame, now);
>
> Is this the correct approach?

If you want to get just one-time values, yes your approach is correct.
If on the other hand you want to get the values on a regular time grid  
(say to produce some ephemeris), then you should rather move all the  
computation statements in a handleStep method that will be called  
automatically for you during the propagation. That is I would  
recommend using master mode instead of slave mode (see  
<https://www.orekit.org/forge/projects/orekit/wiki/Propagation> and  
see  
<https://www.orekit.org/forge/projects/orekit/wiki/PropagationTutorial#Master-mode>).

> Could anyone please give me a hint at how to get the S/C->G/S unit-vector
> in the frame of reference of the S/C with it's attitude applied (parameter
> 4)? I would like to use this vector to extract two angles relative to an
> antenna in order to evaluate the antenna gain in direction of the G/S. My
> basic problem is that I don't really know how I can get the S/C-bound
> Frame that is oriented according to the attitude of the S/C. The only
> S/C-bound frames I can produce are TNW, VNC, QSW/VLVH and VVLH which are
> all not related to attitudes.

The simplest way to do it is as follows, starting from a  
SpecacraftState instance:

 final SpacecraftState state = ...;

 // compose transforms from ground station to spacecraft
 final Transform inertialToSC = state.toTransform();
 final Transform gsToInertial =
   gsTopoFrame.getTransformTo(state.getFrame(), state.getDate());
 final Transform gsToSC = new Transform(state.getDate(),
                                        gsToInertial,
                                        inertialToSC);

 // ground station is at position (0,0,0) in ground station frame
 // see where this point is in spacecraft frame
 Vector3D gsSeenFromSC = gsToSC.transformPosition(Vector3D.ZERO);
 Vector3D unitVector = gsSeenFromSC.normalize();


> In order to get the S/C-G/S-Sun angle (parameter 3), I guess it would be
> enough to get the unit vectors a = G/S->S/C and b = G/S->Sun in a common
> reference frame (e.g. the G/Ss topocentric frame) and then set the angle
> to be equal acos(a.normalize().dotProduct(b.normalize())). Is that
> correct?

It would not be accurate for small angles, as acos behaves badly near  
0. You should rather use Vector3D.angle(a, b). You don't even need to  
normalize, and the angle method takes care of cases near 0 (it uses an  
arc sine there) and near PI/2 (it uses an arc cosine there, just as  
you propose).

> Many thanks for your time and effort for producing this very handy
> library!

Thanks you very much for these kind words, it's really appreciated.

> Best regards,
>
> Raffael Mancini
>
> PS: Have you ever considered introducing a type that would somehow couple
> vectors with frames? This could make it possible either at compile or
> runtime to check if the vectors are in the same frame.

We decided not to do it. Up to a few weeks ago, we had the very low  
level types Vector3D and PVCoordinates, and the higher level  
CartesianOrbit with both PV, date and frame (and also mu but it is  
another story). Then we decided that an intermediate type was needed,  
but it seemed better to have this intermediate with vectors and dates,  
rather than vectors and frames. The rationale was that when you have a  
large ephemeris, all vectors in the ephemeris have the same frame, but  
all have different dates, so it seemed better to associate the  
parameters that change at the same rate (coordinates and time) in an  
object, and to let the frame in the above container. Of course,  
depending on the application, your mileage may vary.

best regards,
Luc

> This message and any attachments are intended for the use of the  
> addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either  
> in whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and  
> delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
>
> Please consider the environment before printing this email.



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.