Changing return type in MeasurementBuilder.build

Orekit development
1

The MeasurementBuilder interface is used by Orekit measurements generation feature. It is specialized for each measurement type. Its build method returns a specific ObservedMeasurement<T> (i.e Range for RangeBuilder, Phase for PhaseBuilder…).

Internally, all implementations work by creating first a dummy ObservedMeasurement<T>, then call its estimateWithoutDerivatives to build an EstimatedMeasurementBase<T>, retrieve from this intermediate object the true measurement value and finally build another ObservedMeasurement<T> with the correct value. This second ObservedMeasurement<T> is then returned through a bunch of classes (AbstractScheduler, then an internal step handler, then Generator). At the end, it is passed to a GeneratedMeasurementSubscriber).

I have a use case where the information present in the ObservedMeasurement<T> is not sufficient; I would need to get the states of the spacecraft involved in the measurement, as they hold some additional states I need. I cannot just call again the propagators that are used by the Generator because doing this stalls the generation (probably some kind of dead lock or infinite recursion as the propagator calls the measurement generator which then would call the propagator back). Setting up another propagator also seems a waste of resources since the states have already been computed during the measurement generation; they were just thrown away when building the second ObservedMeasurement<T> from the EstimatedMeasurementBase<T>.

I would like to change the API of MeasurementBuilder and all the intermediate classes so the measurements that are built and returned to users are EstimatedMeasurementBase<T> rather than ObservedMeasurement<T>. This would of course have to wait for Orekit 13.0 as it is a change in several public signatures. The ObservedMeasurement<T> can be retrieved from the EstimatedMeasurementBase<T> using its getObservedMeasurement() method, but it also contains much more information (states, participants…).

What do you think about this change?

2

Issue 1350 has been created.

3

Hi Luc,

Honestly I don’t know enough Orekit’s architecture for measurement models to comment much. What I would say though is that currently I think things are still too linked to Orekit’s orbit determination system. With Orekit 12.0, we introduced a method to evaluate models without evaluating derivatives in the process, but the signature still requires stuff like the iteration number, which is completely OD related. I think that ideally, the measurement model should be pretty much stand alone, so that people with their own estimation algorithm can plug it in easily.

Cheers,
Romain.

4

I agree iteration number and count are awkward, but they are needed because EstimatedMeasurementBase needs them so the corresponding getters provide meaningful answers. In most cases, when we use the generation API, we just set both to 0 when calling the builder.
May be we could move them down the hierarchy which has recently been split between EstimatedMeasurementBase and EstimatedMeasurement.

5

Yeah why not.

Cheers,
Romain.