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

Re: [Orekit Users] Orekit attitude numerical integration




Joao Silva <jasi@terma.com> a écrit :

Hi all,

Hi Joao,


I am contemplating using Orekit as the kinematics/dynamics engine for a 6DOF
simulator focused on testing Guidance and Control laws.

After studying the documentation I was able to identify most of the critical
components needed for the sim (e.g. orbit propagation, environment models,
navigation algorithms, frame and time definitions, other) but I can't figure
out how to  build the attitude components in a way that allows the control
laws to be tested.

Because of the simulator nature, the satellite attitude/angular rates have to
be propagated/integrated taking into account torques and perturbations from
the actuators which in turn are commanded by the guidance and control laws.
Mathematically it is the same as for the kinematics.

So, my question is:

Does anyone know if all the propagation algorithms provided in Orekit are
tailored for spacecraft kinematics? Or am I missing an implementation for the
spacecraft dynamics?

The propagations algorithms are not taylored for attitude dynamics, but can
handle them, despite it is not obvious. You will have to set up some involved
plumbing to manage everything.

The current workflow for Orekit propagation is that the propagator first
propagate the state (mainly orbital elements but user can add additional
equations and parameters), and adds the attitude on top of it. This is
done throughout the computation so you basically have:

  state(t0) = orbit(t0) + attitude(t0)
         |
       force model integration
         |
         V
  orbit(t1)   -- attitude law  --> attitude(t1) ---> state(t1)
         |
       force model integration
         |
         V
  orbit(t2)   -- attitude law  --> attitude(t2) ---> state(t2)


In classical Orekit use, the attitude law is a predefined law that
implements the kinematics, using the assumption that the AOCS will
be able to set up the dynamics so the perfect attitude law is
achieved. Hence we have perfect pointing, perfect yaw steering...
If the law requires the spacecraft to do a 180° turn in 1 millisecond,
it will do so, which is clearly not realistic. The attitude law, is
however not limited to what Orekit provides as predefined law, you
can add your own laws if you want, you just have to implement a
simple interface.

In your case, you could add in the numerical propagator additional
equations that deal with the attitude and its dynamics, taking the
thrusters, reaction weels, magnetic torquers, you name it. Orekit
will happily integrate these equations and update the additional
states. The trick will be to retrieve this state in a dedicated
attitude law that mainly reformat the state into an Attitude
object, as the numerical integrator will not know that q0, q1, q2,
q3 and their derivatives are really components of a quaternion.
Assuming you can do this, the previous workflow will work. From
Orekit point of view, it integrates an orbit plus something unknown,
then it asks an attitude provider to add an attitude on top of
it and it doesn't realize this attitude provider in fact relies
on the additional state components to provide its answer.
The AttitudeProvider interface has directly no provision for passing
the full state data (you only get the part corresponding roughly to the
orbit), so you will need to establish some bridge to pass the additional
data between the additional equations and the attitude law.

This part may be tricky. If this requires some adaptation of Orekit
to help passing data through, we could discuss about this on the
developers mailing list.

best regards,
Luc


Thanks in advance!

Joao Silva.