Closed jklenzing closed 3 years ago
Include examples of drag coefficients in documentation
This seems appropriate to the discussion:
https://space.stackexchange.com/questions/26117/how-to-generate-tle-file
Highlight:
Making Fake TLEs is dangerous!! You (or others) may end up confusing them with
officially produced TLEs at some later time. It could "poison the deck." The deck
could be yours, or somebody else's.
Dang, the quotes in the above discussion section are great.
In short, you are asking "How to solve this problem the wrong way?"
I think the long term solution is to pull the non-TLE propagator out of another code I have and use it here. Otherwise the mission planning only works for missions in existence.
As a side-note, discovered this post while trying to figure out why readtle
wasn't working for custom built TLEs. Presumably it's because the checksum isn't consistent if I change the inclination. Only getting
ValueError: line does not conform to tle format
in response.
I don’t really find their arguments sufficient to cease activity. I do agree that we shouldn’t make the same approximations in 2018 that were made in the day when TLE was born, yet plenty of folks continue to use TLEs for orbits. Our goal (or at least mine) isn’t to rewrite orbit prop but to use it to support mission development. If there is some other readily available code to do orbit propagation with some initial conditions, then sure, we can have a different orbit simulation instrument. We could perhaps have that anyway, one pysat.Instrument for real TLEs, one for simulated orbits. Otherwise though, a method to support prop of a basic TLE would definitely helpful for mission development.
I currently take an existing TLE from the ISS and modify it as I need to generate supporting proposal plots. They’d likely say that was dangerous and I shouldn’t do it. Perhaps so. Nevertheless, I and others in space science need some way to get simulated orbits. If I can’t do it by specifying parameters then I’ll find some other way, and those other ways could very well be worse.
I think working from existing TLEs is fine, but I'm thinking about creating orbits for missions that don't exist. Having the sgp4 propagate from existing TLEs is good, particularyl for ISS-deployed cubesats. I'm somewhat worried about legal implications for generating TLEs for imaginary spacecraft, particularly if the ID numbers are not sufficiently imaginary.
The other orbital simulator I've used is OrbitalPy: https://pypi.org/project/OrbitalPy/ We had used this for my bubble statistics project. I'll look into a modified version to see if it does what we need, but scanning over the code I think we can just drop it into the pyephem bits. It essentially works from the line 2 components, but as variables (inclination, eccentricity, mean anomaly, etc). This might be a cleaner way of getting what we need for this issue.
Long-term possibility: An sgp4 instrument takes existing TLEs for operating missions and propagates through. An oribtalpy instrument does a rough cut for idealized Keplerian elements.
OK, I think I've found the way forward. It's probably fine to move forward with TLEs as the base, but swapping out the identifiers for zero-filled lines (ie, the zeroth satellite launched in the year zero). I've got a script that can generate fake TLEs, including checksum values.
Looking over the orbitalpy api again, it is likely more limited in terms of what it can generate. Maybe an option to add down the line.
Update: sgp4 has added new methods since this issue was opened for direct access to the parameters we want. See https://pypi.org/project/sgp4/
sgp4.api.Satrec.sgp4init
allows for the direct specification of a satellite via Keplerian orbit parameters.
sgp4.exporter.export_tle
will export tle elements.
Closing with merge of #60. sgp4 allows direct input of Keplerian elements (see #61), making this unnecessary.
Is your feature request related to a problem? Please describe. Often for mission planning, the TLE is needed. Need something that can generate TLEs from user-supplied keywords and vice-versa. Keywords should be physical quantities such as inclination, eccentricity, etc.
Describe the solution you'd like Code should include an orbit dictionary with these keywords. Require functions to translate dictionary into TLEs, and read TLEs into user-friendly ouput.