Parameters for attitude providers

Hi all,

I wonder if we could add parameter drivers for attitude providers.
This could be interesting for example in order to optimize maneuvers directions, as the drivers would be forwarded first from overriding attitude provider to force model, then to propagator, then to optimizer.

I guess this could be added to AttitudeProvider in a minor release with a default implementation that returns an empty list of ParameterDriver.

What do you think?

1 Like

Hi Luc,

So if I’m following well, with that we’d be able to get the variational equations on the thrust direction for LOF-based manoeuvres for example?

Cheers,
Romain.

Exactly.
In fact, this is akin to something Francesco asked me as he is trying to set up something using his new constrained optimization feature.

Thanks. Sounds like a good addition.

Hello,

I do think it’s a good addition too.

Thank you Luc
have an attitude provider that support parameters in a way that manouvre class include them with the other(propulsion and trigger) will help.

Hello
trying to use autodifferentiation for orbital transfer optimizer , my attention was caught on how the Partial for the Duration and MedianDate are calculated.

For the Duration=( Stop-Start) I expect that Jacobian is calculated as:
dYdTm[i] = (dYdT1[i] - dYdT0[i]) instead dYdTm[i] = 0.5 (dYdT1[i] - dYdT0[i])

and for medianDate = (Start+Stop)/2.0 I expect that Jacobian is calculated as:
dYdTm[i] =0.5* dYdT0[i] + dYdT1[i]; instead dYdTm[i] =dYdT0[i] + dYdT1[i];

Am I wrong?
P.S. the jacobian respect to parameters drivers by Matrix Harvester are calculated on normalized parameter or original parameter values?

The computation are correct in the code, I agree this is counter-intuitive.
The rationale is that one can use either the pair start/stop or the pair median/duration but one cannot mix them. When selecting one pair, the fundamental assumption is that the two variables of the pair are the free variables (independent of each other), but that that other pair would be dependent variables.

So when we choose median/duration, we say median is independent of duration, but start and stop both depend on median and duration. Then, if we change median time without changing duration, we shift both start and stop time by the same amount. If we change duration without changing median time, then we change start and stop by half the amount and in opposite directions. This plus differentiation of implicit functions explains the expression in the code.

The expressions have been extensively validated using finite differences (see TriggersDerivativesTest).

thank you for the clarification.

Hi all,

I believe this has never been followed through. Is this something we want to include in future 13.0?

Cheers,
Romain.

2 Likes

I would really love to have this.
I don’t have the time to do it myself, unfortunately.

1 Like

I’ll have a look

1 Like

Hi, if I understand correctly, this would basically enable generic attitude estimation. Is that correct?

1 Like

It is the first step towards this.
One of my dream goals would be to be able to estimate a TorqueFree model (at least initial attitude, perhaps also ratio of inertia).

1 Like

Hi David,

My idea at this stage was to have AttitudeProvider inherit from ParameterDriversProvider with the default being nothing, wiring down to relevant places like AttitudeProviderModifier. But no provider would have drivers defined, it would be down to users to override classes if they want to use it in STM and OD. There could be native stuff in the future I guess but maybe in dedicated classes to avoid messy architecture.

Cheers,
Romain.

2 Likes

The next step would be to have AttitudeProvider.getAttitude() take a parameters argument, just like ForceModel.acceleration() does.
I know it is awkward at least in the primitive double case, this parameter is directly given by calling getParameters on the ForceModel itself, because it extends ParameterDriversProvider, hence the argument could be avoid in this case. This is however important in the field version, as typically it is the caller that knows how to set up the fields when they correspond to gradients with some ordering of the partial derivatives components, so in this case having the caller able to fiddle around between the call asking the force model for its parameters and the call asking the force model for its acceleration is important. We decided to use the same separation with the primitive double so it remains consistent with the field version.

I don’t really like this, it is awkward as I wrote above, but for now we don’t have any cleaner solution.

Hi all,

I’ve added a new interface AttitudeRotationModel whose API is a SpacecraftState and an array of double like the acceleration Luc is talking about (with the Field counterpart). AttitudeProvider inherit from them and bypasses the array, since by default it has no parameter drivers. The new interface is plugged in for the so-called attitude override in Maneuver. I believe this covers your use case @roccafrancesco as you’ll be able to include the related partial derivatives in STM computations.

I’m going to stop here for this release.
I don’t know exactly what we should do next. Touching AttitudeProvider is risky as it’s used a lot and its main API very generic, taking PVCoordinatesProvider as input rather than SpacecrafState. Ultimately for numerical OD we’ll need some sort of builder like OdeintegratorBuilder I guess. I think we should wait a bit and think further.

Cheers,
Romain.

1 Like