Satellite visibility

[Yash-10]

This draft attempt is for satellite visibility with respect to a ground station on the central attractor. Inspired by section 5.4 on rise and set time of a satellite about an oblate planet.

• Currently figuring out the difference between section 5.2.2 and 5.2.5 and which function is the appropriate one.
• Trying to find if the "PREDICT" formulation from Vallado Algorithm 74 would be a simpler choice instead.
• Could check its connection with is_visible method of the SpheroidLocation class and possible refactoring.

Thanks!

[codecov]

Codecov Report

Merging #1299 (88e4934) into main (9d4bc04) will increase coverage by 0.27%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1299      +/-   ##
==========================================
+ Coverage   92.01%   92.28%   +0.27%     
==========================================
  Files          81       81              
  Lines        4256     4278      +22     
  Branches      358      358              
==========================================
+ Hits         3916     3948      +32     
+ Misses        258      248      -10     
  Partials       82       82              

Impacted Files	Coverage Δ
src/poliastro/core/events.py	100.00% <100.00%> (ø)
src/poliastro/twobody/events.py	99.00% <100.00%> (+0.25%)	⬆️
src/poliastro/twobody/orbit.py	85.04% <0.00%> (+0.94%)	⬆️
src/poliastro/plotting/util.py	100.00% <0.00%> (+22.72%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9d4bc04...88e4934. Read the comment docs.

[astrojuanlu]

Would you clarify which "section 5.4" are you looking at?

I would love to see this implemented, because we've been trying for 2 years to get it right:

• [WIP] Implement pass rise and set times predictor #719
• https://space.stackexchange.com/q/49136/10716
• Escobal method satellogic/orbit-predictor#114

I'm eager to understand more about the differences between the method you propose here and the ones we explored earlier.

[Yash-10]

I am sorry, I meant section 5.4 from Escobal's book "Methods for orbit determination". Thank you for the above links, the equation in this pull request (as of now) is the same as the equation you wrote in https://space.stackexchange.com/q/49136/10716. Yesterday, it was modified a bit and hence this pull request (as of now) is aligned with Section 5.4.5, to be specific.

I would have to go through those links and understand the potential pitfalls you mentioned.

Also, I had found some implementations that "seemed" to be relatively straightforward:

• https://github.com/JuliaSpace/SatelliteToolbox.jl/blob/441470938af978e9d5653a9c4b36ccc107023960/src/analysis/ground_stations.jl#L373-L386
• https://github.com/JuliaSpace/SatelliteToolbox.jl/blob/441470938af978e9d5653a9c4b36ccc107023960/src/analysis/ground_stations.jl#L397-L410

These are the ground_station_visible methods.

[Yash-10]

I had some thoughts on the Escobal's approach to solve satellite visibility. As I see, that method is intended to be applied once per orbital period. Even though Escobal's approach could work here, I think, due to the nature of the event checking procedure in poliastro, we might not necessarily need to formulate such an analytical equation since we check for event at each time step?

What I tried to do in the current implementation here was somewhat inspired by Example 5.9 from Howard Curtis's fourth edition. It gives slight errors in the event detection time (ranging from ~1 s to ~2 min, in rare cases more than that) when compared to orekit's ElevationDetector, while for some lat and lon values of the ground station, the implementation matches.

• Since I explicitly used the "Greenwich" mean sidereal time for calculating the local sidereal time, I think this is still restricted to Earth. Once the current addition seems to exactly match with orekit, extension to any general body could be made.
• Some (lat, on) pairs for ground stations for which I get mismatch with orekit: (78, 10), (90, 5), (45, 45). (lat, on) pairs like (50, 5), (20, 10) matches with orekit.

This could imply the current addition might be closer to being correct, however there are some intricacies that would need investigation for the above slight errors.

Any suggestions would be helpful here!

---

I used this to make orekit's elevation detector:

from org.orekit.bodies import GeodeticPoint
from org.orekit.frames import TopocentricFrame
from org.orekit.propagation.events import ElevationDetector

point = GeodeticPoint(78 * DEG_TO_RAD, 10 * DEG_TO_RAD, 0.0)  # (lat, lon, height)
topo_frame = TopocentricFrame(Earth_orekit, point, "earth-station")
...
...
ElevationDetector(topo_frame).withHandler(StopOnEvent())

Any thoughts @astrojuanlu @jorgepiloto ?

---

Also when I tried to check, as a first pass, by using: https://docs.astropy.org/en/stable/api/astropy.coordinates.AltAz.html to extract the alt property and just returning that or by using LST directly from https://astroplan.readthedocs.io/en/latest/api/astroplan.Observer.html?#astroplan.Observer.local_sidereal_time, the event times seems to be the same from what I have tried to implement here.

[Yash-10]

As @astrojuanlu pointed out in the meeting to check the ellipsoid that I used for validating the event, I came to know that I had made a foolish error by comparing event times with the flattened earth from orekit, as was done for the other events. Now I changed that:

• Now the 6-7s mismatches, as stated above, do not occur!
• I only seem to observe mismatches for the ground station (lat, lon) cases (in degrees): (45, 45), (45, 46), (46, 45), (47, 45) whereas the times match for all the other cases (at least from the several lat-lon values I checked).

Is there any particular consequence of having both lat and lon values closer to 45 degrees for the ground stations, in general, in orbital mechanics?

---

Update: I again tried to check today and found that errors for (45, 45) case no longer appears, but I didn't change anything in the code! So the only pairs where the error occurs now is (46, 45) and (47, 45) where the mismatch is around ~5600 seconds.

I think these errors were somewhat sporadic.

[Yash-10]

Although a pull request was made: poliastro/validation#35, the deviations with orekit at two (lat, lon) pairs would need some inspection.

I tried to add some graphs in poliastro/validation#35.