Proposed change to measurement classes that accept Receivers

Orekit development
1

I am currently using the least-squares algorithm with the TDOA and FDOA measurement classes for some research I am performing. The issue I’m having is: the T/FDOA measurement classes assume that the receivers creating the T/FDOA values are on the ground, and the code is written with this assumption baked-in. However, the receivers I am working with are in space. The current structure of the code is:

TDOA extends GroundReceiverMeasurement {
    TDOA(GroundStation primary, GroundStation secondary, ...) {
    }

    EstimatedMeasurementBase<TDOA> theoreticalEvaluationWithoutDerivatives(...) {
        final GroundReceiverComonParametersWIthoutDerivatives common = computeCommonParametersWIthout(SpacecraftState) {
            ...
    }

    EstimatedMeasurement<TDOA> theoreticalEvaluation(...) {
        final GroundReceiverComonParametersWIthDerivatives common = computeCommonParametersWIth(SpacecraftState) {
            ...
    }
    
}

GroundReceiverMeasurement extends AbstractMeasurement {
    GroundReceiver(Groundstation station, ...) {
    }

    GroundReceiverCommonParametersWithoutDerivatives computeCommonParametersWIthout(SpacecraftState state) {
    
    }
    GroundReceiverCommonParametersWithDerivatives computeCommonParametersWIth(SpacecraftState state) {
    
    }
}

# Standalone class
GroundStation(TopocentricFrame baseFrame)

# Math implementation classes
GroundReceiverCommonParametersWithoutDerivatives
GroundReceiverCommonParametersWithDerivatives

What I’d like to change the structure to in order to make it more flexible is:

TDOA extends AbstractMeasurement {
    TDOA(Receiver primary, Receiver secondary) {
    }

    EstimatedMeasurementBase<TDOA> theoreticalEvaluationWithoutDerivatives(...) {
        final ComonParametersWIthoutDerivatives common = computeCommonParametersWIthout(SpacecraftState) {
            ...
    }

    EstimatedMeasurement<TDOA> theoreticalEvaluation(...) {
        final ComonParametersWIthDerivatives common = computeCommonParametersWIth(SpacecraftState) {
            ...
    }
}

# New child classes
GroundReceiver extends Receiver
SatelliteReceiver extends Receiver

# New parent class
Receiver() {
    CommonParametersWithoutDerivatives computeCommonParametersWIthout(SpacecraftState state) {
    
    }
    CommonParametersWithDerivatives computeCommonParametersWIth(SpacecraftState state) {
    
    }
}

Obviously the other measurement classes that rely on GroundReceiver would be updated similarly, and it wouldn’t be possible to push this to main until v14. And the actual implementation might end up looking a little different than this, since this is only a first draft solution. But in general what does everyone think of this idea?

2 Likes
2

I would love to have a higher level abstraction for receiver, encompassing both ground stations ans spaceborne receivers, this would reduce code duplication significantly and would be easier to understand.

One thing that may be tricky is the fact that for spaceborne receivers, the receiver is often the thing we want to estimate, but sometimes it is the other way round, and sometimes both link ends have to be estimated. We already have the possibility to estimate the receiver position for ground stations (slightly adjusting it be estimating some Cartesian offsets), but it is clumsy.

We need to design a better architecture.

1 Like
3

Yes I’m looking at InterSatellitesRange right now and it looks like in that case ObservableSatellite is used to represent both the sender and the receiver of the signal. However when I look at GroundStation and ObservableSatellite I don’t think it would take very much to make ObservableSatellite the child of a Receiver class that would be able to incorporate both.

4

Draft MR is up. Please feel free to share thoughts.