Clarity in getAcceleration method in the ThrustPropulsionModel class

Orekit usage
1

Hi,

The ThrustPropulsionModel (OREKIT 12.2 API)" describes the getAcceleration​ method as “Get the acceleration of the spacecraft during maneuver and in maneuver frame. Acceleration is computed here using the thrust vector in S/C frame.”

How are the maneuver frame and the s/c frame defined?

In my script, I have the getAcceleration method defined as follows that computes the acceleration in the spacecraft frame.

def getAcceleration(self, s, maneuverAttitude, params):
        '''
        get the acceleration vector in spacecraft frame
        '''

        thrust_vector = self.getThrustVector(s)
        acceleration = thrust_vector.scalarMultiply(1.0 / s.getMass())

        return acceleration

My overall script gives me the desired results. However, i am wondering if i am doing anything wrong here because clearly I am not considering any “maneuver frame” separately in my script.

The following is how I am defining a custom maneuver and adding it to my propagator:

customManeuver = Maneuver(None, maneuverTrigger, customPropulsionModel)
propagator_num.addForceModel(customManeuver)

Any advice will be much appreciated.

1 Like
2

Hello @Stella28,

During the propagation, the spacecraft has an attitude profile attached to it defined by an AttitudeProvider, which you can optionally pass during construction of the NumericalPropagator. If you don’t specify it, the propagator uses a default attitude model. I don’t exactly remember what’s the default attitude, but I seem to remember that for quasi-circular orbits the X axis is aligned with velocity and Z with opposite of position vector (take the “aligned” with a grain of salt, since I don’t know if the attitude is position-based or velocity-based).

When you build a maneuver you can specify a new attitude that overrides the one used during propagation. This attitude is only used to compute the thrust vector and does not affect other forces that depend on the attitude of the satellite (like drag if you are using a non-isotropic body shape), as was asked (by me a while ago :grin:) here.

In your case, the propagator is using the default attitude to compute the maneuver direction. In general, I’d say it’s better to specify the attitude override when building the maneuver to be sure that the thrust direction is the one you really want when transformed in the inertial frame for the integration.

3

@Emiliano Thank you for your response.

I have noticed that adding an AttitudeProvider override in initializing Maneuver like you suggested (Case 1) v/s not adding any attitude override (Case 2) is not changing the results in my case.

Case 1:
offset_frame = LofOffset(frame, LOFType.QSW)
customManeuver = Maneuver(offset_frame, maneuverTrigger, customPropulsionModel)
propagator_num.addForceModel(customManeuver)

Case 2:
customManeuver = Maneuver(None, maneuverTrigger, customPropulsionModel)
propagator_num.addForceModel(customManeuver)

Probably this is because of how i have set up my customPropulsionModel? This is just a speculation as I am not clear on how the prescribed maneuver attitude is supposed to work.

In my understanding, prescribing None as attitude provider should apply the maneuver in the default attitude of the spacecraft, whereas prescribing an attitude provider should change the maneuver attitude to align with the prescribed one (QSW == RTN in this case).

As shown below, in my customPropulsionModel, I transform my RTN thrust vector to the spacecraft frame (irrespective of the attitude provide prescribed for the maneuvers). Is this why prescribing a maneuver attitude is not working in my case?

def getThrustVector(self, s):
        '''
        Get thrust vector in spacecraft frame
        '''

        thrust_vec_RTN = self.thrustDirectionProvider.computeThrust(s)

        Rotate_RTN_to_ECI = LOFType.QSW.rotationFromInertial(s.getPVCoordinates()).revert()
        thrust_vector_ECI = Rotate_RTN_to_ECI.applyTo(Vector3D(thrust_vec_RTN[0], thrust_vec_RTN[1], thrust_vec_RTN[2]))

        rotation_ECI_to_scFrame = s.getAttitude().getRotation()
        thrust_vector_scFrame = rotation_ECI_to_scFrame.applyTo(thrust_vector_ECI)

        return thrust_vector_scFrame

def getAcceleration(self, s, maneuverAttitude, params):
        '''
        get the acceleration vector in spacecraft frame
        '''
        thrust_vector = self.getThrustVector(s)
        acceleration = thrust_vector.scalarMultiply(1.0 / s.getMass())

        return acceleration

def getDirection(self, s):
        '''
        Get thrust direction in spacecraft frame
        '''
        thrust_vector_scFrame = self.getThrustVector(s)
        thrust_mag = thrust_vector_scFrame.getNorm()
        direction_scFrame = thrust_vector_scFrame.scalarMultiply(1.0/thrust_mag)
        
        return direction_scFrame

My ultimate goal is to define a fixed attitude to my spacecraft during the maneuvers.

4

I think the reason you don’t see any change if you provide an attitude override is that in your propulsion model you’re defining the maneuver in RTN and then rotating it to SC frame (passing through ECI). The propagator then transforms back to ECI during integration, using the SC attitude.
Basically if you account for all the matrices used both by you and the propagator, the thrust is being multiplied by the attitude matrix and by its inverse: the sequence RTN -> ECI -> SBF you’re doing in getThrustVector is then being reversed by the propagator (which does SBF -> ECI).

You could avoid doing the rotation in your class by simply providing the thrust in RTN and specifying the attitude override as in Case 1 (i.e. LofOffset(frame, LOFType.QSW))

5

@Emiliano,

What you mentioned regarding propagator converting the thrust vector back from sc_frame to ECI for propagation makes sense. In my Case 2, where getThrustVector returns the thrust vector in sc frame (and the AttitudeProvider == None in initializing Maneuver also depicts that the maneuvers are in the sc_frame), the propagator simply takes that vector and transforms it to ECI, and thus I get the expected results.

However, I still don’t understand how Case 1 is giving the expected results. There basically i am returning the thrust vector in spacecraft frame from getThrustVector, but Maneuver initialization is indicating that the thrust vector is in RTN frame. Going by the same analogy as before, I would imagine the propagator in this case will wrongly assume the thrust vector is in RTN (as attitude provider in Maneuver initialization says so) and will try to convert it from RTN to inertial, which should not work!

Same way, let’s call this Case 3, your suggestion of returning RTN thrust vector from getThrustVector and initializing Maneuver with LofOffset(frame, LOFType.QSW) makes sense to me. However, to my surprise that doesn’t give me the desired results as well.

In all these cases, my RTN thrust vector shows Tangential thrust being applied (long burn arcs), however i don’t see the expected semi-major axis raise in Case 3, when i plot my trajectory orbit elements. In fact I see no effect of the thrust in my trajectory! And I don’t understand how I am seeing the desired results in Case 1 (as discussed above.)

Feel like I am missing some critical concept here!

6

@Stella28,

With the code you pasted before, Case 1 and Case 2 will always return the same results because the attitude override is never used in your model. I didn’t realize you’re also overriding getAcceleration. Inside your getAcceleration implementation you’re only dividing the thrust by the mass. In the base implementation of this method instead, the maneuverAttitude is used to rotate the thrust vector to ECI.

In your case, I think what’s happening is a combination of 2 things that results in the correct output:

  • 1: you’re building the propagator without specifying the attitude provider, so it’s using the default one.
  • 2: the output of your getAcceleration method is actually still in SC frame. It’s just that SC frame is ECI.**

To have the correct behavior with Case 3 you should have your getThrustVector return +/-Y (if you’re using RTN) and then use the default implementation of the getAcceleration method (or alternatively make sure to use the maneuverAttitude to rotate the thrust vector).

**I have to correct my previous statement: I think the default attitude is acutally aligned with ECI. Indeed, if you build a propagator without specifying the attitude provider and then run prop.getAttitudeProvider().getAttitudeRotation(prop, date, eci) and you extract the quaternion you will get [1,0,0,0], meaning SC frame and ECI are aligned.

7

@Emiliano,
Thank you very much for the clarification. That makes total sense.
Returning the acceleration vector in the same frame as s.getFrame() (which is inertial in my case) solved the issue here.

I should indeed be using the default implementations of getAcceleration and getDirection methods to avoid any confusion. However since i am using jpype, I am running into some issues with using the default implementation. I get the NoSuchMethodError when i do not define the @JOverride for the getAcceleration() method.

I guess till I figure out the jpype issue, i just need to make sure getAcceleration returns the acceleration in the same frame as s.getFrame(). And getDirection() returns the vectors in the same frame as self.getThrustVector method does. In my case, when i am returning RTN thrust vector from getThrustVector(), getAcceleration should return acceleration in inertial and getDirection should return the direction in RTN. Defining the attitude override in Maneuver initialization to RTN, ties everything together the right way.