Using Skyfield to model fictional satellites #384
Comments
|
Thank you for the very kind comments! They are a big encouragement to a project maintainer. And I am glad that Skyfield helped accelerate your work! Skyfield does support the creation of satellite objects from raw orbital elements, if you lack a TLE and want to build the elements from the ground up — or, rather, the SGP4 library underneath has support. It can also, if I recall, generate a satellite from a position and velocity. But neither of those possibilities seems to be documented in Skyfield's satellite documentation, so I will go see about getting some sample code written up this afternoon, and then I'll comment back here with a link to the new draft documentation. As for satellite behavior: do you know whether the cubesats you are studying have internal propulsion and perform orbital correction maneuvers? That is the biggest variable I can think of in long-term prediction. If they perform no course corrections, then I would expect the long-term propagation by SGP4 to give a rough idea of how the orbit would look in the future — even though the accumulated error might have the position off by a whole half-orbit, or have the altitude wrong because the average drag in SGP4 is a poor match for the actual space weather the satellite encountered each month in space. But SGP4 run into the future will gradually degrade the orbit, and might be a good match for how an unpowered cubesat would evolve. If course corrections are made, though, then at that instant the old SGP4 solution becomes not only a bad prediction of position, but in addition becomes a bad model for even the shape of the orbit, and would cease to be valid. Here's a test you might try. The Skyfield documentation links to the Internet Archive, which can be used to fetch old TLE coordinates from cached versions of the Celestrak site: https://rhodesmill.org/skyfield/earth-satellites.html#historical-satellite-element-sets I'm not sure how you would identify an unpowered satellite in an orbit similar to your cubesat, but if you could do so, then you can directly answer your question with a quick simulation. Use the Internet Archive to download several TLEs over several years for the unpowered satellite in an orbit like your cubesat. Then, compare: run your analysis against only the earliest TLE, propagated forward through those several years, and then run again against the n TLEs that you were able to download up to and including the current one. If the results agree, then you have your answer: the old initial TLE is enough for your algorithm. If they disagree, then your task will be harder, as only a set of TLEs representing different times will give you accurate results. Of course, depending on what you are measuring, it might be that there's no substantial difference over long periods of time — that any orbit, given its declination and approximate altitude, will have very similar solar characteristics to any other. You might want to pull TLEs for lots of satellites within the same envelope of orbit shapes, and see if the solar characteristics are very satellite-individual or whether just a few variables, like inclination and orbit size, might alone be correlated with how much power is available. |
Ohhh thank you! This would be absolutely awesome! I would really appreciate it!
Theoretically, I suppose that a fictional satellite I model could maneuver but for now I consider this beyond the scope of the simulation. In those cases, I might just create a new object for the new orbit and carry over all other satellite data.
This was a really good suggestion! I just did this simulation for a few items. Here's UWE-3 calculated using TLE data from April 2, 2014 compared with today's TLE on that same satellite.
The difference in eccentricity is pretty significant but the difference in orbital period and inclination are not very different in at least this very specific case (polar orbit for a small satellite with little drag) the error in the amount of sun it receives is not significant even after 6 years of no station-keeping. I'll go about finding a few satellites to test in different orbits. That said, if larger satellites were considered by my simulation, I think it would be fair to assume that those satellites would engage in regular station-keeping maneuvers. In that case, I think it'd probably be appropriate to ignore drag, right? I'd like to test that. Do you think I could do that by just setting the BSTAR value to 0 or very close to it and changing the checksum on line 1 of the TLE?
|
It wound up requiring a little bit of extra code to get Skyfield to accept an already-built satellite object. To get the new bit of code, you'll want to install the development version of Skyfield: Once that's installed, the following new technique for building a satellite from raw elements should start working! Building a satellite from a position and velocity will require a bit more work. There's a little routine buried deep in the source code that looks like it does the conversion: But the elements it returns do not have a 1-to-1 correspondence with the orbital elements that the In any case: if you need
Good, that's a pleasant simplification to be able to make for now. It was only a few days ago that I happened across this Space Exploration question, whose answers have several graphs showing when the ISS gets boosted into a higher orbit each time it decays:
I'm glad the suggestion was helpful! That's a bigger difference in eccentricity than I would have guessed — I wonder what the physical cause is. I would imagine (but I'm not a flight engineer! I'm just using my imagination) that satellites get re-boosted into very similar orbits to what they have before they decayed, but I don’t actually know; maybe evolving missions make it attractive to tweak the orbit at the same time to optimize for other features other than an exact match for the previous orbit? I'll be interested to hear what happens if you drop drag to zero, or close to it; no, I have never tried that tweak, and can’t predict whether SGP4 will be well-behaved or go a bit wild if it doesn’t have a nice solid drag number to chew on. :) |
Thank you so much for taking the time to do this. I'll take a look at this tomorrow and get back to you but I have to go to work soon.
It appears that setting BSTAR to zero and changing the checksum to match actually does greatly improve the performance of the TLE files over long periods in the few tests I did on this today (I'll try to set up an automated test of this tomorrow). In the case of UWE-3, the change was minimal, which was expected given how little drag it experiences:
In a worst case scenario, I looked at the ISS, which has enough drag to require orbit maintenance maneuvers but otherwise fits my assumption that maneuvers are only used to stay close to some ideal orbit. It turns out that in this case, setting BSTAR to zero does work really well! These are the numbers comparing the accuracy of a TLE file from 2014 with one from this afternoon.
Reducing drag to zero might let these models actually be useful several years out, provided that my assumption about orbit maintenance maneuvers is correct. This issue is the eccentricity seems to get very large, and I'm also at a loss as to why. That said, I think the next step is to test A) that this behavior applies to all orbits and B) that the amount of sunlight each satellite gets on average over many days does not change significantly, provided that the inclination and orbit period stay the same. I'll pop back and let you know both of my results in this thread in a bit when I can verify these. |
|
Ok! So I tested the update you made at it works a charm! I'll pop back into this thread later tonight or tomorrow afternoon with an update discussing long-term accuracy of SGP4 if you set BSTAR and/or the ballistic coefficient to zero, just so that if people need to be able to do this in the future, they can know roughly what level of inaccuracy to expect. I'll also include how different the solar/thermal characteristics are between the accurate and older data, just to satisfy the curiosity of you/anyone else reading this thread. Other than that though, you've solved my issue :) Thank you very much!
|
|
I have just released Skyfield 1.22 which supports the new satellite constructor; you should no longer need to install from the zip file to use the new feature. Enjoy! I'm going ahead and closing the issue to clear the dashboard, but I look forward to any further comments about the results you generate. |
|
Just a comment for readers who came this far. Why do the Orbits of Satellites like ESA's XMM-Newton change, and are regularly updated and published for e.g. here TLE?
|
|
@cruisen — Thank you for those details! It is always so helpful to hear from an expert on an issue like this one where my knowledge is limited. |
Hello!
I posted an issue seeking help for my satellite solar panel simulator project a few days ago and you were extremely helpful. The first iteration of this project is now done and models an existing cubesat pretty well, so thank you! However, I'd like the tool to be useful for planning when designing new satellites. For this, I want to be able to model satellites that do not exist yet and thus don't have TLE files on CelesTrak. Ideally, I'd like to be able to use Skyfield for this, since Skyfield makes it really easy to get the angle/distance to the sun's observed position. It would also be nice if I could have orbits that make sense even after several years so I could begin to simulate things like battery/solar panel degradation over time. Does Skyfield provide facilities for this already? If not, would the underlying sgp4/sdp4 library be suitable for this, given the requirement that orbits should make sense even after a few years (to be clear, they don't need to be accurate, they just need to make sense). Admittedly, I don't know much about how error accumulates in SGP4, so I don't know if the orbits start to get wild looking/invalid.
Failing this, I guess I can model these things myself and then create the appropriate position/velocity objects in Skyfield when I want to make comparisons like that. Are there any gotchas or things you think I should watch out for if I take this approach?
PS This library is easily the best maintained and documented library I've worked with while working on this project. I just want to say thank you because so far, between the features of the code itself and your assistance in my earlier question, your library has easily saved me two or three weeks of work minimum.
The text was updated successfully, but these errors were encountered: