Hi there. I am trying to figure out a way to set a two axis pointing with +x pointing to the Sun and +y pointing to the ground, but still cannot find a valid solution. The celestial body pointed gives the possibility to set the phasing over Z not over Y. Which is the correct way to implement it then, on your opinion?

Hi @jordan_93

The `CelestialBodyPointed`

does allow to select Y as the phasing direction (just put `Vector3D.PLUS_J`

as the last constructor argument), but this will not suit your needs, because the phasing reference in celestial frame is fixed and you need it to change as your satellite moves around the Earth.

I guess the simplest way to achieve what you want is to develop a custom implementation of `AttitudeProvider`

. Getting just the rotation right is trivial using the `Rotation`

constructor that uses two pairs of vectors: the desired rotation is the one that transforms the sat-sun direction into +x and the nadir (or Earth center depending on the attitude design) direction to +y. Take care to use sat-sun as the first vector in the pair, because this one will be exactly aligned whereas the second vector (nadir) only defines a meridian plane, because the angular separation between sat-sun and nadir may be different from Ď€/2 whereas the angular separation between +x and +y is always zero, so the constructor has to assumes which vector has higher priority.

Getting the rotation-rate and rotation acceleration on the other hand may be tricky. So the best way to get it correct is in fact to not use `Rotation`

in the trivial computation above, but to compute the various vectors and rotation with derivatives embedded and to unpack the derivatives later on. This is done by using `PVCoordinates.toUnivariateDerivative2Vector`

first so that sat-sun and nadir vectors really includes derivatives, and then to build a `FieldRotation<UnivariateDerivative2>`

from these vectors as explained above with the two-pairs constructor. Once you have a `FieldRotation<UnivariateDerivative2>`

, you can build a regular `AngularCoordinates`

from it, has there is one specialized constructors that knows how to extract derivatives from a `FieldRotation<T>`

is `T`

is some kind of derivatives (i.e. either `DerivativeStructure`

, `UnivariateDerivative1`

or `UnivariateDerivative2`

).

If this seems too complicated, ask again for help.

I have thought a little further on this, and think your need may be generalized and Orekit could provide an implementation.

Could you open a feature request asking for an attitude provider (say `PointingAndPhasingProvider`

) that would take two `DirectionProvider`

(a new interface in the same spirit as `PVCoordinatesProvider`

except it would take into account the current state as the origin and would compute a unit direction and its derivatives). The first direction provider would define the exact pointing for one spacecraft axis, and the second one would define the phasing plane (i.e. it would perform angular separation correction just like the two vectors pairs constructor of `Rotation`

).

In addition, a simple generic wrapper `DirectionToTarget`

would implement `DirectionProvider`

from a `PVCoordinatesProvider`

acting as the target and mainly subtract current state to compute the state to target direction.

`CelestialBodyPointed`

could be reimplemented as a class extending `PointingAndPhasingProvider`

, but this not interesting for you. What would be more interesting for you would be to use `PointingAndPhasingProvider`

with the pointing direction provider built as a `DirectionToTarget`

wrapping the celestial body while the phasing direction provider would be built either as a `DirectionToTarget`

wrapping a fixed `PVCoordinatesProvider`

representing the origin (if phasing towards center of Earth) or something more sophisticated if phasing towards nadir.

Hi @luc and @jordan_93,

I had faced a similar issue sometime back and was discussed in the forum too. But could not get anytime to proceed further with the implementation. I guess it would be great to revisit and work on it right now. And I can say the feature request is already open (around similar lines) here.

Do we still need a new issue?

@luc thank you for the explanation above, which definitely seems not easy. Two things:

- I tried to implement this problem, giving as phasing_cel the opposite of the vector earth-sat in inertial frame as follows:

Sun_Earth_Pointing = CelestialBodyPointed(EME2000_frame, sun, Spacecraft_State.getPVCoordinates().getPosition().negate(), Vector3D.PLUS_I, Vector3D.PLUS_J)

Is it a wrong way to implement it?

- Since @gowtham already opened the issue, should I anyway open a new one?

Many thanks,

Filippo

The implementation with `getPosition().negate()`

and `Vector3D.PLUS_J`

is semantically correct, but as the position is time-dependent, it is doomed to fail: it is only valid at the time you sample the position.

No need to open the issue, we will focus on @gowtham one, and it is definitely something that should be provided by the library itself.

Yes, I was considering this date dependency, thatâ€™s why I was calculate the new vector every step of the propagation and update it everytime.

Not the most efficient solution, but definitely a workaround I think. Thank you very much for the help

Thanks for the issue then @gowtham. How long usually these kind of issues are provided?

The detector cannot be updated after propagation starts, so this either would not work or means you change propagator at each step which will be tremendously costly in computation time.

It depends on available work resource. If someone from the core Orekit team was involved, it could be done in a few hours, butâ€¦ we are busy. This problem is not really complicated, but it is not trivial either, so I would not put an â€śeasy to fixâ€ť label on it. It would however be a great first contribution for anyone, and would really add an important feature. Of course, this would take more time for a new contributor to do it, but he or she would learn quite a bit by doing so. So I would really really like to see someone cut his or her teeth on it, otherwise, yes, the core Orekit team will do it, when we find time

Hi !

I have an additional comment. By following the Orekitâ€™s contribution guidelines it is very easy for the Orekit team to provide help during the contribution. A contributor is never alone when doing a contribution, the Orekit team is always happy to provide help.

(Especially with the Field implementations which are not easy for a first contribution )

Bryan