I’ve recently been working with FieldOfViewDetector in which I would like to see when a satellite FoV enters the area defined inside this method. In summary, I am propagating the satellite by using its TLE data and I am using the following lines for the detection:
# Setting up propagator with simple nadir pointing attitude.
attitudeProvider = NadirPointing(TEME, earth)
SGP4 = TLEPropagator.selectExtrapolator(mytle, attitudeProvider, satellite_mass)
...
# Setting up the station point and its frame.
R_earth = Constants.WGS84_EARTH_EQUATORIAL_RADIUS # Radius of earth
Mu_earth = Constants.WGS84_EARTH_MU # Gravitational parameter of earth
f_earth = Constants.WGS84_EARTH_FLATTENING # Earth flattening value
earth = OneAxisEllipsoid(R_earth, f_earth, ITRF) # Create earth here.
station = GeodeticPoint(latitude, longitude, altitude)
station_frame = TopocentricFrame(earth, station, "Esrange")
...
# Finally defining FoV and setting up its detector.
fov_margin = 0.0
FoV = CircularFieldOfView(Vector3D.PLUS_K, radians(45.0), fov_margin)
FoVDetector = FieldOfViewDetector(station_frame, # Target PV
100000.0, # Target radius
VisibilityTrigger.VISIBLE_AS_SOON_AS_PARTIALLY_IN_FOV,
FoV).withHandler(ContinueOnEvent())
Everything seems to be working in order until I compare the entrance-exit results of the satellite with another open source library (predict4java). Above code finds FoV entrance time 8-10 sec before, and finds exit time 8-10 sec after what the other open source code calculates.
This difference is really bugging me and I am trying to find an answer to it. I’ve actually tried many cases, presenting some of them just to narrow down possible problems:
It is interesting that if I lower the FoV angle to a limit, say 0.1 degrees, this difference vanishes!
Position and velocity results of both codes are in perfect compliance, so propagator works okay.
I also tried setting the center of the target right on the Equator. This does not have any effect on the aforementioned difference.
Keeping FoV angle same, analyzed satellites having different altitudes such as 350 km and 1700 km.
At this point I am suspecting that the problem may be related to the FoV and the utilization of CircularFieldOfView method.
I would really appreciate any ideas regarding this issue!
Looking very briefly at predict4java code, and in particular looking at the calculateRangeCirclePoints method in the SatPos class, they do not seem to take
into account Earth flattening. The equations seem to consider Earth is
a perfect sphere (but I just looked quickly). In order to check if the discrepancy comes
from this crude approximation, you can try to model Earth as a perfect sphere in Orekit too.
I quickly tried your suggestion by setting the earth flattening to zero. It does not seem to have an effect on the results, discrepancy persists
As the FoV angle is further increased, the difference between results are also increasing. Considering this finding, I think the issue is about generated FoV. However I do not know for certain what it is.
As you consider the target is a 100km sphere centered at the station, and as FieldOfViewDetector does not consider Earth surface as opaque, maybe you see part of the sphere that is below ground instead of when the roughly circular shape corresponding to intersection with ground enters the satellite FoV?
Yes I suppose this might be the problem. I quickly lowered the target sphere radius to 5 km and the detection difference is almost gone.
In this case, how should I implement this? I mean, how can I use a “spherical cap” instead of a “spherical target” in FieldOfView method? Or is there any workaround you are aware of?
You can use FootprintOverlapDetector. Beware it is based on sampling the region, so you need to use some sampling step in meters on ground. If you use a too small sampling distance, then the region may end up containing millions of points and detection will be very slow. If you use a too large sampling distance, the region will only contain a few point and detection will be inaccurate.
There is no rigorous and fast way to do what you want yet. The reason is that intersecting a region defined on an ellipsoid (the Earth) and a region defined on a unit sphere with a moving center (the unit sphere around spacecraft) is difficult. We know how to intersect SphericalPolygonsSet instances very fast, but only when they are defined on the same object.
I see, so that the workaround. I tried FootprintOverlapDetector before but it usually takes longer to compute specific cases whether I enter small or large sampling value. Also, we have to enter SphericalPolygonSet as zone in the FootprintOverlapDetector method. So at first glance, I cannot be sure if I can implement a circle easily or not.
Thank you for the valuable discussion @luc, I appreciate it.
Okay I tried FootprintOverlapDetector and after numerious trials and errors, I managed to eliminate the discrepancy which is the main idea of this topic.
For those who want to use custom zones within FootprintOverlapDetector method, beware the following argument:
FootprintOverlapDetector method is working perfectly well with country coordinates but for some reason I was unable to define a simple circle (yes a circle) in the method. Apparently, while creating the circle I desire, the consecutive coordinates I input was in clockwise orientation. However, in order to avoid the error thrown by Java, you must enter coordinates in counter-clockwise orientation.
I wanted to point out this issue so that people would not be stucked at this point if they ever trace the steps I am following now.
