I wanted to propose a fitting organization for the
forces.maneuvers package. This package is, in my opinion, currently a bit basic and lacking in Orekit.
This is not an enhancement I would think of adding to version 10.1 so there’s no rush and we have time to discuss it.
My first motivation is to implement a constant thrust maneuver where the thrust and direction can be estimated in orbit determination. With current maneuver package it would mean copy/pasting most of the code of ConstantThrustManeuver class (which for now can just estimate the thrust norm or the flow rate).
@cbamann asked how to estimate and impulse maneuver (presumably ΔV based) in this topic. A proposed work around was to implement a very small thrust maneuver and do the conversion from ΔV to thrust by hand. But I guess we could do better, especially if the user wants to estimate the 3 components of the ΔV or retrieve the covariances associated with the ΔV.
For now our unique maneuver force model (ConstantThrustManeuver) is based on built-in date detectors. For station keeping purpose a user could want to have detectors based on orbital events, with a thrust value, direction and duration that could be optimized with a batch least-square algorithm. Or a user could want to detect an impulse maneuver, estimating its ΔV and date through an orbit determination…
There are many use cases that we fail to cover with the current maneuvers’ package and I would like to propose an architecture that would attempt to correct this, or at least lay the first stone that will help improve this in the future.
Current maneuvers package architecture
For now the maneuvers package has the following classes:
ImpulseManeuver: this is actually a detector for impulse maneuver, not based on the ForceModel interface. It’s convenient but cannot be used to estimate maneuvers in orbit determination;
SmallManeuverAnalyticalModel: this is an analytical model for small maneuvers; it doesn’t implement the ForceModel interface;
ConstantThrustManeuver: a constant thrust maneuver with DateDetectors for start/end date and the possibility to estimate either the thrust norm or the flow rate. It implements the ForceModel interface.
It is mainly that model that I’d like to enhance.
Draft architecture proposal
I would like to not introduce APIs changes so that we could release something in a minor version (say 10.2).
My idea would be to create a generic
Maneuver class that has 3 attributes:
AttitudeProvider(may be null) that will override the current Spacecraft attitude to allow for a dedicated maneuver attitude. It is actually needed for compatibility reason with current
PropulsionModelobject that will hold everything that is propulsion related: thrust, deltaV, isp, flow rate etc. and the corresponding parameter drivers for estimation with a batch least-square or a Kalman filter.
This will allow users to implement their own propulsion model, constant or variable, thrust or ΔV-based; and their own paramers for estimation.
PropulsionModelwill help covering points 1, 2 and 3 in the Motivations part of this post.
ManeuverTriggersobject that will contain the start and stop triggers for the maneuver. These triggers can be based on EventDetectors. They can also hold specific parameter drivers that would be used in estimation; for example to optimize a thrust duration, or estimate a maneuver date given satellites’ measurements.
ManeuverTriggersaims at covering point 4 in the Motivations part of this post.
Maneuver class doesn’t hold any physical data, it is an orchestrator.
It provides generic implementations for the methods
getParameterDrivers of the
These generic implementations calls dedicated methods in the
ManeuverTriggers that will do the actual computations and have to be developed by the user.
I pushed a maneuver-package branch on the git repository to propose a first implementation of this architecture.
(It is not up to date with the latest commit on develop branch since it doesn’t contain the data-context enhancement written by Evan. But this won’t be an issue and I will do it later on).
It covers only point 1 for now… and is not tested.
The class diagram below illustrates its content. Sorry if it’s in a shambles but I struggled with PlantUml and since it’s not definitive I don’t want to spend hours making it super clean .
I added some variable thrust related classes to show where they would interface.
I removed the Field-based methods for readability but they exist.
This is just a draft. It is organized as follows:
Maneuver class is the orchestrator
triggerpackage contain the maneuver triggers objects:
ManeuverTriggersgives the methods needed to implement the triggers
DateBasedManeuverTriggersreproduces the existing behavior of
ConstantThrustManeuver, i.e. the maneuver is defined by a start date and an end date. It does not contain any parameter driver.
For now this is the only available maneuver triggers object.
propulsionpackage contains the propulsion model objects:
PropulsionModelgives the methods needed to implement a propulsion model
ThrustPropulsionModeldefines methods for a thrust-based propulsion model and computes the acceleration and mass derivatives given current thrust vector and flow rate
ThrustPropulsionModelfor a constant thrust. It mainly removes the dependency to current
SpacecraftStatein thrust vector and flow rate computations.
BasicConstantThrustPropulsionModelextends previous class and is used to reproduce the behavior of existing
ConstantThrustManeuver. It can estimate the thrust norm or the flow rate.
ScaledConstantThrustPropulsionModelextends abstract class above and has 3 parameter drivers that are scale factors for the thrust on S/C X, Y and Z axis. It allows for a 3-D estimation of the thrust.
ThrustPropulsionModeland holds the model for a variable thrust maneuver. It has to be implemented.
ConstantThrustManeuverclass is a rewritten version of the existing class. It takes a
AbstractConstantThrustPropulsionModelas argument. With this it can have all the previously defined public method (for compatibility reasons) and the user can use its own custom constant thrust propulsion model.
VariableThrustManeuverclass has to be implemented. It would take
Once again, a draft implementation is available on the maneuver-package branch for those of you who want to check it out.
@dorian: would this architecture be ok for the variable thrust propulsion model you wanted to add ?
To all: what do you think of this ? Would you be interested in that feature ?
I’m very open to changing the architecture and/or the names of the classes. And I’m not an expert in class designing, so feel free to comment and criticize !
Maneuver triggers package is very small for now but it could grow in the future.
I had other classes ready for propulsion model package, mainly ΔV based models, but they made the UML diagram look so ugly that I just dropped them for this post.
I’m realizing I’ve started written a novel so I will stop my post here.
Thank you for reading all this, and sorry for its length.