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.
2 Likes
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.
1 Like
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?
1 Like
@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.
1 Like
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 
1 Like
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
2 Likes