¿Cómo se puede predecir una órbita con base en una posición inicial y un vector de dirección inicial?

He estado desarrollando un simulador planetario en Unity 3D (C#) y necesito ayuda, sin embargo, creo que este sería un mejor lugar para ello. Estoy comenzando mi planeta desde un vector de posición. En la inicialización, aplico un vector de dirección, que lo pone en órbita alrededor de una estrella más grande. Las órbitas no son circulares y me gustaría que fueran elípticas.

He leído sobre los focos, el semieje mayor y el semieje menor, sobre varias leyes de Newton y Kepler, entiendo la apoapsis y el periapsis y, sin embargo, no puedo entender qué debo hacer. Lo que he hecho es dejar un rastro de los planetas y se pueden ver las órbitas. (nota: ¡Sé que el diseño de los planetas no es correcto!)

planetas

Se ve bien, pero no es lo que quería. Me gustaría poder predecir la órbita. Encontré ecuaciones para poder calcular la esfera de influencia, que requieren el semieje mayor. Podría calcular el semieje mayor si tuviera el tiempo orbital, y podría calcular el tiempo orbital si tuviera el semieje mayor. Sin embargo solo tengo una posición inicial, un vector de fuerza que le aplico, la distancia entre los planetas, y también las masas de cada uno. Estoy en un callejón sin salida aquí, no estoy seguro de lo que estoy buscando. ¿Alguien podría darme algunos consejos (o fórmulas) para hacer lo que me gustaría hacer?

Agradecería mucho cualquier ayuda, gracias de antemano!

¿Qué quiere decir exactamente con "vector de dirección inicial"? Si es lo que creo que quiere decir (la unidad tangente), no puede "predecir una órbita, en función de una posición inicial y un vector de dirección inicial". El vector de posición tiene tres grados de libertad, pero el "vector de dirección inicial" solo tiene dos. Sea cual sea el esquema que se utilice para describir una órbita (y hay muchos), se necesitan seis parámetros independientes en una época específica. Solo tienes cinco.
Trabajé durante unos meses en un juego/simulación y finalmente tuve que renunciar a la idea de hacer algo matemáticamente elegante. Podría usar las leyes de Kepler para las órbitas, SI asumes que los planetas no tienen efecto entre sí. Para los planetas, eso es bastante correcto, pero menos para los satélites y mucho menos para las naves espaciales. Tuve que ir con Newton y hacer un enfoque puramente iterativo. Divide el tiempo en segmentos lo suficientemente pequeños y calcula todas las fuerzas en cada objeto en cada incremento. Simple, pero no puedes predecir dónde estará algo en el futuro sin calcular cada momento intermedio.

Respuestas (3)

En tres dimensiones necesitas seis números. Lo que está preguntando es cómo convertir de un conjunto de seis números, tres coordenadas de posición y tres componentes de velocidad (tenga en cuenta que simplemente la dirección no es suficiente), a otro conjunto de seis números, los seis elementos orbitales.

No voy a darte las ecuaciones, pero te ayudaré a empezar. Puedes googlear las ecuaciones. Primero calcule la energía, un escalar. Eso te dirá si incluso está en órbita (energía negativa) o hiperbólica (energía positiva). A partir de la energía, puede calcular fácilmente el semieje mayor. Luego calcule el vector de momento angular. La dirección de ese vector te dirá el plano de la trayectoria y la dirección en ese plano (ese vector es perpendicular al plano de la trayectoria). Luego calcule el vector de excentricidad. Ese vector estará en el plano y apuntará al periápside o punto más cercano de una hipérbola. Su magnitud es, por supuesto, la excentricidad de la órbita o hipérbola.

Entonces tendrás todo lo que necesitas para generar los elementos orbitales.

Encontré algunas ecuaciones y hacen referencia al uso de G... curiosamente en mi simulación, no he usado G... simplemente he hecho F = (m1*m2)/d^2. Cuando lo sustituyo, simplemente sale volando y no presta atención a la órbita.
Lo que normalmente verás es la combinación GRAMO METRO del cuerpo central, a veces acortado a m . En el mundo real, nunca usamos GRAMO , porque podemos medir GRAMO METRO con mucha más precisión que cualquiera GRAMO o METRO .
Tengo algunos problemas para calcular el semieje mayor. En primer lugar, calculé la velocidad orbital (para que se pueda conectar a la otra ecuación). solía v = r o o t ( METRO / r ) . Luego calculé la energía orbital con mi = v 2 / 2 ( metro 1 + metro 2 ) / r . Luego usé la ecuación v 2 = ( metro 1 + metro 2 ) ( 2 / r 1 / a ) , y reorganizado para encontrar a, el eje semi-mayor. Sin embargo, la longitud cambia a medida que el planeta orbita... ¿Alguna idea de por qué está haciendo esto?
Primero, necesitas GRAMO frente a todos los metro 's. En segundo lugar, sus ecuaciones dan como resultado mi = m 2 a , de donde puedes obtener a . mi es una constante de movimiento, por lo que calcularía el mismo valor en cada punto de la órbita. (No utilice mi para la energía específica ya que ese es el símbolo de la excentricidad.)
Por cierto, si estás asumiendo v = m r , entonces estás asumiendo una órbita circular. Después r no cambia, y a = r .

Esta rutina del kit de herramientas JPL/NAIF SPICE OSCELT responde a lo que parece ser una consulta sobre el problema de los dos cuerpos.

NB: supongo que su "vector de dirección" es en realidad un "vector de velocidad"; la entrada de ESTADO a OSCELT es un vector de seis elementos que es la concatenación de los vectores de posición y velocidad.

NB, como se indicó anteriormente, necesita un séptimo número: MU, el valor GM para el cuerpo central.

Técnicamente también necesitas un octavo número, el tiempo de las condiciones iniciales, para tener un punto de partida para calcular las efemérides futuras (y pasadas).

Ese enlace es para la versión FORTRAN del kit de herramientas SPICE porque eso es lo que Google devolvió primero. También hay interfaces C, IDL, Matlab, Java e incluso Python informales para SPICE; debería ser posible crear una DLL de la versión C que se pueda llamar desde C#.

No haré esto más largo de lo que tiene que ser: hojee las páginas de SPICE; SPICE tiene una curva de aprendizaje empinada, pero vale la pena el esfuerzo. La documentación es la mejor que encontrará en cualquier lugar, o comuníquese conmigo para obtener más detalles.

Perdone mi falta de una respuesta concreta, pero realmente depende de qué tan preciso deba ser. Una vez escribí un simulador que usaba una aproximación newtoniana de n cuerpos. Era agradable, pero no particularmente bien implementado y solo podía soportar un par de docenas de cuerpos antes de que se ralentizara a paso de tortuga.

KSP utiliza un enfoque más simple y escalable; una nave espacial solo se siente atraída por el cuerpo cuya esfera de influencia habita, y los planetas y las lunas están sobre rieles. Esta es una aproximación lo suficientemente cercana para un videojuego, y no se descontrola a medida que agrega más objetos a la simulación. La compensación es que significa que solo te sientes atraído por un objeto a la vez, por lo que no ves puntos de Lagrange u otros efectos gravitacionales interesantes.

Incluso un modelo newtoniano de n cuerpos bien implementado sería mucho más costoso desde el punto de vista computacional que el sistema de KSP, y aún así no contaría toda la historia, ya que la física newtoniana no tiene en cuenta los efectos relativistas. (Si cree que los efectos relativistas no son importantes para la mecánica orbital, lea sobre el planeta Vulcano: https://en.wikipedia.org/wiki/Vulcan_(hypothetical_planet) )

Podría valer la pena hacer esta pregunta sobre el intercambio de pila de Game Development, ya que decidir cómo aproximarse mejor a una órbita tiene tanto que ver con el tipo de juego que desea y las limitaciones prácticas del hardware informático disponible como con la física de mecánica orbital.

OP nunca menciona que esto es para un juego, o que la intensidad computacional es un problema. En realidad, al leer la pregunta, tengo la impresión opuesta, que su simulador planetario ahora está desarrollado con la precisión de un planetario, pero le gustaría simular órbitas futuras de objetos arbitrarios con mayor precisión ingresando sus efemérides. TL; DR Dudo mucho que la cinemática simplificada como los usos de KSP sirvan.