[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Dear Luc,

first of all, thanks a lot for your quick and helpful answer! Is still
have a few questions.


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>).


I will do this once I get all the geometry right. I will create a custom
pass detector that checks if a list of unequalities described as strings
(e.g. "e > 5.0") are all true for the S/C to be considered "visible". For
now I've written the pass detection code myself.


> 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();


Does this code take into account the attitude specified in the propagator?


Yes.


What attitude is used when no attitude is specified in the propagator
constructor? In general, are attitudes only handled at the level of the
propagator?
There is a default attitude set up for each propagator, so there is always an attitude available. In general attitudes should be handled by propagator, however, you can had them afterwards taking the propagated spacecraft state and giving it to an external AttitudeProvider. It would be kind of waste of computation, though, because the propagator already does this first with the default attitude provider, and then you would do it again, so just giving the propagator your AttitudeProvider beforehand would save one layer of computation. 



I think my understanding of attitudes is still quite rough at the moment,
especially when it comes to specifying degrees of freedom that are not
explicitely specified by the law. How would I for example specify the
following attitudes?

1. Inertial attitude with a specific Rotation at a specified point in time
This would be done using two fixed attitudes linked into one attitude sequence containing only one switch, at fixed time. 


2. Z-axis pointing nadir with the x-axis colinear to the earth rotation
axis
This would be done by wrapping a nadir pointing within another custom provider you would write that would add the necessary rotation around z. 


3. Target pointing to some earth G/S with additional requirements on
either x- or y-axis
Same has point 2, but wrapping another ground pointing provider instead of nadir pointing. 

best regards,
Luc




> 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)


Ah, I haven't thought about that I've changed it in my code.

Best regards,
Raffaello Mancini
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.