Salida de efemérides de Skyfield

¿Es posible usar Skyfield para propagar un TLE hacia adelante y luego generar sus efemérides, en lugar de x, y, z geométricas en algún momento en el futuro?

He trabajado con los ejemplos en la API y es posible que haya leído algo mal, pero parece que todas las salidas disponibles son para eventos de eclipse, horas de salida y puesta, ángulos de visión, etc. Me gustaría ver los seis elementos (SMA, excentricidad , inclinación, RAAN, ArgP, anomalía media) para que pueda ver lo que sucede entre los TLE publicados.

Puedo ver una manera que podría funcionar. Parece correcto en principio, aunque soy un poco cauteloso porque soy nuevo en Skyfield:

  • propagar un TLE a la nueva hora
  • posición de salida.km
  • velocidad de salida.km_per_s
  • ensamblarlos junto con la nueva época para producir un nuevo vector de estado (derivado de SGP4) en ese momento
  • derivar elementos orbitales del pos-vel

Esto parece más bien una chapuza si la capacidad ya existe.

La posición y la velocidad en alguna época son una forma de efemérides. En mi opinión, la posición/velocidad en una época es una mejor forma de efemérides que una TLE, siempre que la posición y la velocidad en esa época no se deriven de una TLE. SGP4 no es tan bueno como propagador (y eso es ser bueno). El objetivo era hacer algo que pudiera propagar órbitas usando tecnología del siglo anterior (¡milenio anterior!), y hacerlo usando tecnología de punto flotante de precisión simple.
Una efemérides es una tabla de posiciones (y opcionalmente velocidades) en varios momentos. Los elementos orbitales no son efemérides: son instrucciones sobre cómo calcular una efeméride, que a veces es más útil que la efeméride en sí misma, y ​​otras veces no. Un TLE son instrucciones sobre cómo configurar solo una pieza de software en particular, SGP4, para calcular una efemérides, y esa es la única cosa para la que se debe usar SGP4: convertir TLE en tablas de pos y vel, y luego procesar con algo más, con mejor física y definiciones menos confusas.

Respuestas (2)

Skyfield, como la mayoría de las otras herramientas que afirman tener la capacidad de procesar datos TLE, depende de las conjeturas educadas pero antiguas de un grupo de personas sobre lo que SGP4 podría haber estado haciendo hace algún tiempo, en lugar de dar acceso a lo que SGP4 realmente hace en este momento. Esto tuvo sentido durante mucho tiempo porque la mayoría de las personas no tenían otra forma de obtener SGP4, pero afortunadamente ese ya no es el caso. Cualquiera que se registre para obtener una cuenta gratuita ahora puede descargar la implementación oficial del gobierno de EE. UU. de SGP4 y las utilidades asociadas, algunas de las cuales se actualizaron significativamente en noviembre de 2020, desde https://www.space-track.org/documentation#/sgp4 .

Para ver el código del que hablo a continuación, debe aceptar las restricciones de la licencia de código abierto de SGP4 (que aparecerán cuando haga clic en el enlace de descarga, y luego estarán disponibles para su referencia como \Sgp4Prop_small\SampleCode\*\SGP4_Open_License .txt), descargue ese archivo, descomprímalo y observe el contenido de Sgp4Prop_small\SampleCode\Python\wrappers\ y Sgp4Prop_small\SampleCode\Python\DriverExamples\Sgp4Prop\src\ . El código contenedor también se proporciona en C, C#, Fortran, Java, Matlab y Visual Basic (las bibliotecas reales se proporcionan como DLL para Windows y .so para Linux), pero usted preguntó sobre Python, así que lo describiré todo desde el Punto de vista de Python.

Como parte de esa actualización, el envoltorio de Python provisto finalmente cambió de Python 2 a Python 3 (Sgp4Prop.py como se incluye con las versiones de la biblioteca hasta la 7.9, sin cambios desde enero de 2013 pero aún se distribuye en octubre de 2020, colapsó bajo Python 3 porque no estaba usando paréntesis en declaraciones impresas, entre otras fallas básicas). Personalmente, incluyo algunos ajustes propios que creo que hacen que las bibliotecas sean más fáciles de usar, como agregar un __init__.py vacío al directorio y anteponer puntos para convertir las llamadas de los envoltorios de la biblioteca entre sí de importaciones absolutas a relativas, pero eso es completamente opcional y no forma parte de la distribución oficial, que es todo lo que voy a detallar en este momento.

La única cosa claramente no Pythonic con la que lidiar es que la interfaz proporcionada por los contenedores predeterminados sigue exactamente el antiguo estilo C y Fortran, por lo que todas las funciones solo devuelven un código de estado entero. Los datos regresan tal como están escritos en estructuras que debe declarar previamente usando ctypes y proporcionarlos como argumentos de entrada, lo cual no es difícil, pero no es la forma en que se usa normalmente Python. Es muy posible ocultar todo eso escribiendo sus propios envoltorios, lo que he hecho por mí mismo pero que aún no he puesto a disposición de nadie fuera del trabajo.

La tarea de convertir un TLE en una tabla de elementos keplerianos osculadores de la mejor manera disponible, utilizando de la forma más correcta posible todos los modelos SGP4, es una de las cosas básicas que se muestran como ejemplo en el script de demostración, Sgp4Prop_small\SampleCode\Python\DriverExamples \Sgp4Prop\src\Sgp4Prop.py. Esa secuencia de comandos toma la desafortunada elección (la línea 129 llama a TimeFunc.TConLoadFile) de querer que proporcione los tiempos de inicio, finalización y paso del archivo en el dolorosamente arcaico e innecesariamente confuso formato de "tarjeta 6P" (p. ej., como se describe en las páginas 7 –9 de Sgp4Prop_small\Documents\librarydocuments\TimeFunc.doc), pero la biblioteca TimeFunc proporciona todas las funciones de conversión necesarias para generar el formato de hora que el propagador quiere recibir (días decimales desde 1950, UTC) de cualquier otro dato de hora que pueda tener .

... para que pueda ver lo que sucede entre los TLE publicados.

Esta es una gran razón para desear una función de este tipo; observar la evolución de los elementos orbitales a lo largo del tiempo puede proporcionar una idea intuitiva de lo que está sucediendo. (ejemplos: 1 , 2 ). No le dice de inmediato dónde está la nave espacial en un punto dado ni qué tan rápido va (eso es lo que los clientes de vectores de estado generalmente quieren), ¡pero sería una excelente opción!

No sé si está en Skyfield todavía o no (pero estoy bastante seguro de que no), pero el sitio de Github es bastante activo e incluso hay una página de discusiones además de la página de problemas .

Tal y como yo lo veo, hay varios caminos a seguir:

  1. Calcule un convertidor de elementos keplerianos osculadores desde un vector de estado único o una matriz a un elemento de órbita osculador único o una matriz, que es lo que tiene Horizons. (pero vea los problemas con los elementos keplerianos a continuación)
  2. Calcule un elemento orbital medio aproximado similar a SGP (¿contendría los términos de arrastre de SGP?)
  3. Calcule algo mejor o más estándar que SGP, tal vez elementos orbitales medios de Brouwer-Lyddane.
  4. ¡Todo lo anterior!

Space SE ciertamente tiene todas las ecuaciones para convertir un vector de estado en una órbita Kepleriana basada en la fuerza central de la Tierra. GRAMO METRO , pero se garantiza que están equivocados por orden de una parte por mil porque ni siquiera incluyen la oblación de la Tierra expresada por j 2 ni ningún otro efecto, así que no creo que esto esté en la carrera por lo que quieres.

Esto es fácil de ver; obtenga los elementos osculadores de algunos objetos en Horizons por, digamos, diez veces distribuidos en un período y vea cuánto varía realmente cada elemento orbital dentro de una sola órbita.


Más lecturas aquí:

Más lecturas fuera del sitio: