Implementation of variable date ManeuversModel

Hi,

I’m currently attempting to compute a maneuver plan (several maneuvers) in order to achieve specific orbital parameters.

I’m having trouble implementing my ForceModel regarding maneuvers. I’ve seen the thread https://forum.orekit.org/t/partial-derivatives-w-r-t-maneuver-objects/1155/2
that I’m basing my implementation as it seems similar.

My constraints are the following :

  • The maneuver parameters that I wish to optimize are the delta_V and the starting date of thrust.
  • Thrust always aligned with SC’s velocity
  • I’m using orekit 9.2.
  • I’m neglecting any change in the SC’s mass

I gathered that, based on current deltaV and the starting date, I can compute the maneuver final date (assuming constant thrust) as

duration of thrust = deltaV * m / F

Hence, the delta V variation is only elongating the maneuver and the duration on which the acceleration thrust is active.

My acceleration method is as follows :

public <T extends RealFieldElement> FieldVector3D acceleration(final FieldSpacecraftState s,
final T[] parameters)
throws OrekitException {

    if (firing) {
    	
        // compute thrust acceleration in inertial frame
    	
    	final T deltaV = parameters[0];
    	final T date = parameters[1];
    	final Field<T> field = s.getDate().getField();
    	
    	final T duration = deltaV.multiply(this.mass/this.THRUST_FORCE);
    	ffinal T thrust  = duration.multiply(deltaV.getReal()/this.mass);
    	
       
        Vector3D velocityDir_REF = s.getPVCoordinates().getVelocity().normalize().toVector3D();


        
        final FieldVector3D<T> fieldDirection = (FieldVector3D<T>) s.getPVCoordinates().getVelocity().normalize();

       						
        return new FieldVector3D<>(thrust  ,fieldDirection);



    } else {
        // constant (and null) acceleration when not firing
        return FieldVector3D.getZero(s.getMass().getField());
    }
}
My problem is twofold ;

The jacobian that I’m computing (through an implementation of the MultivariateJacobianFunction interface) gives me no variations wrt orbital parameter whatsoever.
This seems to indicate that the parameters that I’m looking at (DV & date) have no influence althrough the parameter is used whithin the acceleration computation.

I’m less sure about the date (parameter[1]). It fixes the date at which the acceleration contribution is to be added. But I only use it for the determination of the
firing boolean through the following method

@Override
public <T extends RealFieldElement> Stream<FieldEventDetector> getFieldEventsDetectors(final Field field) {
// in forward propagation direction, firing must be enabled
// at start time and disabled at end time; in backward
// propagation direction, firing must be enabled
// at end time and disabled at start time

    final FieldDateDetector<T> startDetector = new FieldDateDetector<>(new FieldAbsoluteDate<>(field, this.date_start)).
        withHandler((FieldSpacecraftState<T> state, FieldDateDetector<T> d, boolean increasing) -> {
            firing = d.isForward();
            return FieldEventHandler.Action.RESET_DERIVATIVES;
        });
    
   
    final FieldDateDetector<T> endDetector = new FieldDateDetector<>(new FieldAbsoluteDate<>(field, this.date_end)).
        withHandler((FieldSpacecraftState<T> state, FieldDateDetector<T> d, boolean increasing) -> {
            firing = !d.isForward();
            return FieldEventHandler.Action.RESET_DERIVATIVES;
        });
    
    return Stream.of(startDetector, endDetector);
}

Any Idea on why I can’t seem to get a non zero jacobian ?
Since the date parameter is not directly within the acceleration method, how can I get it’s influence on orbital parameters ?

Hi !

Welcome to the Orekit forum :slight_smile:

Work is in progress to add this functionality in Orekit.
See: issue-856 branch and maneuvers-dates-derivatives branch

Best regards,
Bryan

It should be available now (at least in a branch). See issue 865.

The branch is expected to be merged in develop so the feature should be available in Orekit 11.1.

It was not as easy as I first thought :disappointed_relieved: