Incorrect micro-fluctuations in FOV detector between two satellites

Orekit Python Wrapper usage
1

Hello everyone !

I am currently simulating a satellite A defined on a 550 km-SSO that is pointing towards a satellite B defined from an ephemeris at first (not working) and also towards geodetic points at different altitudes (workaround).
The goal is to shift the pointing law to study the effect of a delay and see when satellite B leaves the FOV of the satellite A, wich is pointing to the nominal position of sat B. I’m propagating these for 10 min and 15 min.

For now, I consider a perfect pointing law (no delay). However, my FOV logs look strange: instead of having a single continuous visibility window, I get many “micro-logs” of AOS/LOS …

At first, I tried to directly set the attitude of A to B with a CelestialBodyPointed attitude. Since the ephemeris start date is days after the definition of A orbit, I can’t use a CelestialBodyPointed attitude since the ephemeris doesn’t exist yet. The SSO is defined on 01/11/2027 and the propagation start on, 21/11/2027.

So I have the following code :

...
initial_orbit_date = AbsoluteDate(2027, 11, 1, 0, 00, 0.0, TimeScalesFactory.getUTC())
# Start date of the propagation
initial_date = AbsoluteDate(2027, 11, 21, 6, 50, 00.0, TimeScalesFactory.getUTC())
date = absolute_to_datetime(initial_orbit_date).replace(tzinfo=timezone.utc)
desired_mlt = 20
sun_ra = get_sun_ra(date)
raan = mlt_to_raan(desired_mlt, sun_ra)
....

attitude = CelestialBodyPointed(
        ephemeris.getFrame(),
        ephemeris,
        Vector3D.PLUS_I,
        Vector3D.PLUS_K,
        Vector3D.PLUS_J,
    )
propagator_sat.setAttitudeProvider(attitude)

final_ephemris_state = ephemeris.propagate(initial_date, initial_date.shiftedBy(10*3600.0))
final_satellite_state = propagator_sat.propagate(initial_date, initial_date.shiftedBy(15*3600.0))

Leading to :

 org.orekit.errors.TimeStampedCacheException: impossible de générer des données avant le 2027-11-21T07:28:52.62583672683195Z, données requises pour 2027-11-01T00:00:00.000Z qui est 1,754932625836727E6 s avant
        at org.orekit.utils.SortedListTrimmer.getNeighborsSubList(SortedListTrimmer.java:87)
        at org.orekit.utils.ImmutableTimeStampedCache.getNeighbors(ImmutableTimeStampedCache.java:113)
        at org.orekit.utils.TimeStampedCache.getNeighbors(TimeStampedCache.java:55)
        at org.orekit.propagation.analytical.Ephemeris.basicPropagate(Ephemeris.java:368)
        at org.orekit.propagation.analytical.AbstractAnalyticalPropagator.propagate(AbstractAnalyticalPropagator.java:148)
        at org.orekit.propagation.AbstractPropagator.propagate(AbstractPropagator.java:275)

Propagating both with this attitude at the inintial_orbit_date works, but it’s not what I want.
I tried to counter this by changing the attitude to an AttitudesSequence , since my ephemeris is defined by hundreds of points (I know it’s not ideal, but the attitude is working). So basically, I’m creating the initial CelestialBodyPointed by a sequence of TargetPointing , defined by a set of GeodeticPoint.

...
attitude.append(
            TargetPointing(propagator_sat.getFrame(), GeodeticPt[i], earth)
        )
for j in range(1, len(attitude) - 1):
        attitudesSequence.addSwitchingCondition(
            attitude[j - 1],
            attitude[j],
            Date_detect_list[j],
            True,
            False,
            4.0,
            AngularDerivativesFilter.USE_RRA,
            None,
        )

propagator_sat.setAttitudeProvider(attitudesSequence)
attitudesSequence.registerSwitchEvents(propagator_sat)

I’m then using a FOV detector to see when the sat B is exiting or entering A’s FOV with the following :

center = Vector3D.PLUS_K
axis1 = Vector3D.PLUS_I
axis2 = Vector3D.PLUS_J
fov = DoubleDihedraFieldOfView(center, axis1, 2.5, axis2, 2.5, 0.0)

FOV_detector = (FieldOfViewDetector(ephemeris, fov).withHandler(ContinueOnEvent()))
propagator_sat.addEventDetector(FOV_detector)

By doing that, I have some micro-logs, which are unexpected …

 	AOS_FOV                              LOS_FOV
2027-11-21T07:28:52.62583672683195Z   2027-11-21T07:30:38.34695068822741Z
2027-11-21T07:30:38.34695075894177Z   2027-11-21T07:30:59.5492103450827Z
2027-11-21T07:30:59.54921034561062Z   2027-11-21T07:31:16.52717941515576Z
2027-11-21T07:31:16.527179419432Z     2027-11-21T07:31:33.55401504182868Z

....

Which is obviously incorrect. I should not have anything log yet since I’m pointing toward the reel position of Sat B …

The idea is then to create a temporal attitude biais (what if I target the sat B 10s to soon ? Is the reel sat B still visible by A ?)

If you have any ideas on these two issues, please let me know.

Thanks for the help !

Emilien

1 Like
2

Hello @Emilien_mrlt,

I lack time to adress your biggest issue but i can already answer the second one.

You can do so using an EventShifter wrapping your FOV detector and coupled with an AttitudesSequence (Orekit 13.1 documentation).

I’ll try to look into your other issue when i have more time.

Cheers,
Vincent

1 Like