Issue with the FootprintOverlapDetector's access result

Orekit usage
1

Hi all:
I am new to Orekit and have been tring to learn it and develop with it over the past few weeks. As an open source library, Orekit has surprisingly rich resources and methods in space dynamics, it is a great pleasure learning and using it. However I find an issue that can’t be solved by myself after tring to do so for a few days:
I am trying to use the FootprintOverlapDetector to calculate the access time window for a ground area and a CircularFieldOfView has been set. It works just fine, but the access times seems not the same with result from STK.
My access times( Orekit):
image
STK’s:

AreaTarget5-To-Sensor4
----------------------
                  Access       Start Time (UTCG)           Stop Time (UTCG)       Duration (sec)
                  ------    -----------------------    -----------------------    --------------
                       1    6 Dec 2021 23:27:51.886    6 Dec 2021 23:29:50.136           118.250

And my code is shown as below:

Frame frameEme2000 = FramesFactory.getEME2000();
		Frame frameEcf = FramesFactory.getTIRF(IERSConventions.IERS_2010);
		AbsoluteDate date = new AbsoluteDate(startTime.getYear(), startTime.getMonthValue(), startTime.getDayOfMonth(),
				startTime.getHour(), startTime.getMinute(), startTime.getSecond(), TimeScalesFactory.getUTC());

		Orbit orbit = new KeplerianOrbit(a, e, i, omega, raan, u, PositionAngle.TRUE, frameEme2000, date, Constants.WGS84_EARTH_MU);
		KeplerianPropagator keplerianPropagator = new KeplerianPropagator(orbit);

		OneAxisEllipsoid earthShape = new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS,
				Constants.WGS84_EARTH_FLATTENING, frameEcf);

		FieldOfView fieldOfView = new CircularFieldOfView(Vector3D.PLUS_K, FastMath.toRadians(45.),
				FastMath.toRadians(0.));

		SphericalPolygonsSet targetArea = buildTargetArea();

		final double maxcheck = 60.0;
		final double threshold = 0.001;

		PolygonVisibilityHandler polygonVisibilityHandler = new PolygonVisibilityHandler();

		FootprintOverlapDetector detector = new FootprintOverlapDetector(fieldOfView, earthShape, targetArea, 1000.)
				.withHandler(polygonVisibilityHandler).withMaxCheck(maxcheck).withThreshold(threshold);

		keplerianPropagator.addEventDetector(detector);

		AbsoluteDate endDate = new AbsoluteDate(endTime.getYear(), endTime.getMonthValue(), endTime.getDayOfMonth(),
				endTime.getHour(), endTime.getMinute(), endTime.getSecond(), TimeScalesFactory.getUTC());

		final SpacecraftState finalState = keplerianPropagator.propagate(endDate);
2

Hi @yang welcome,

The FootprintOverlapDetector is a special case. It is less accurate than other events detectors because it is based on sampling of the ground zone, and there is very little control over this sampling. If the ground zone has irregular boundaries, or long strips (like fjords or peninsulas), these features may be missed be the detector.

Also I see you are using a KeplerianPropagator, which is really not accurate. Keplerian orbit will diverge from real orbit a lot.

So I would suggest first to switch to a better propagator and ensure you use the same perturbations for both STK and Orekit, and if this does not improve the results, then reduce the sampling step size (but of course this will increase the computation overload).

3

Thank you a lot for this fast reply!
First of all, the zone I am working with is a quite simple polygon:

954a2587fe83283ead0e7b2591c2e1b
954a2587fe83283ead0e7b2591c2e1b787×614 30.5 KB

And actually i’ve tried to use both NumericalPropagator and KeplerianPropagator to calculate the access windows, it turns out that comparing with STK (two body and HPOP), the position and velocity of the satellite is basically the same, but both access windows are quite different with the STK’s.
Another fun appearance is that if i set the FOV’s halfAperture to like FastMath.toRadians(180), and do the same in STK, the differences between the time windows will almost be gone( <50ms).

4

Then maybe this is a problem with attitude.
You did not specify any AttitudeProvider in your code, so you end up with a default provider which is inertially oriented. I guess you should set up something like NadirPointing or similar.

1 Like
5

Wow, i’ve never thought about that.

6

It works!
Thank you for your efficient and useful reply. Now that I have no further questions, I wish you a wonderful weekend! :smiley: :smiley: :smiley: