Skip to content
This repository has been archived by the owner on Oct 14, 2023. It is now read-only.

Satellite visibility #1299

wants to merge 8 commits into
base: main
Choose a base branch


Copy link

@Yash-10 Yash-10 commented Aug 5, 2021

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.


Copy link

codecov bot commented Aug 5, 2021

Codecov Report

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

Impacted file tree graph

@@            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/ 100.00% <100.00%> (ø)
src/poliastro/twobody/ 99.00% <100.00%> (+0.25%) ⬆️
src/poliastro/twobody/ 85.04% <0.00%> (+0.94%) ⬆️
src/poliastro/plotting/ 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.

Copy link

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:

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

@astrojuanlu astrojuanlu mentioned this pull request Aug 7, 2021
1 task
Copy link
Member Author

Yash-10 commented Aug 7, 2021

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 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:

These are the ground_station_visible methods.

Copy link
Member Author

Yash-10 commented Aug 15, 2021

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 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")

Any thoughts @astrojuanlu @jorgepiloto ?

Also when I tried to check, as a first pass, by using: to extract the alt property and just returning that or by using LST directly from, the event times seems to be the same from what I have tried to implement here.

Copy link
Member Author

Yash-10 commented Aug 23, 2021

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.

Copy link
Member Author

Yash-10 commented Aug 30, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants