Help with Orbit Math please

[grom]

I am trying to work out some orbital maths. The problem I'm working on is when to launch in order to rendezvous with a station. To simplify I'm assuming orbits along the equator plane. So far I've code code for converting between state vectors and orbital elements http://grom.zeminvaders.net/orbitsim/orbit_calc.html and a basic ascent simulator (which currently ignores atmosphere and uses a pitch of 45 degrees so is not optimal - its in very raw form) http://grom.zeminvaders.net/ascent.html

At the moment how it works is once the rockets orbit (AP) will intersect with the stations orbit I stop simulating it and keep simulating until the station reaches that point on the orbit. On IRC someone gave me this equation on how to find the time to reach a position in the orbit given current position of station:

http://integrals.wolfram.com/index.jsp?expr=sqrt%28l%2F%28GM%29%29x%2Fsqrt%28%28e^2-1%29x^2%2B2lx-l^2%29&random=false

l = semi latus rectum

e = eccentricity

x = distance between centers

I don't understand how to simplify this equation in order to convert it into code. So my aim is when I calculate the rocket will intersect the stations orbit that I use a formula to calculate the time it would take for the station to reach this position.

[Alias72]

could the poster who answers this also explain the process for the community. I am sure some people (me) will find it very useful and will be very grateful to you.

[Bill Phil]

It may be better to just rendezvous once in orbit. It's easier, but really you do want to get close after launch. I usually just eyeball it because I don't want to go through all that stuff with numbers at the moment...

[Vanamonde]

This sort of orbital mechanics discussion belongs in Gameplay Questions. And so, moved.

[Srpadget]

What I think you're asking for is known professionally as "the prediction problem" or "the Kepler problem". Or, at least, that's a major aspect of the overall problem you're working on.

Kepler lived 400 years ago. And it is STILL known by a phrase containing 1) the name of the guy who first took a serious crack at it four hundred years ago, and 2) the word "problem". This should tell you something.

Flipping through my ancient college textbook "Fundamentals of Astrodynamics" (written by 3 professors at the US Air Force Academy), I see a major section of Chapter 4 is devoted to this. Several pages of vector math featuring determinants of matrices, some 3-space vector differential equations, efforts to invert them using seemingly-arbitrary variable substitutions, peppered with phrases such as "...these equations are indeterminate for..." and "...a better approximation is obtained from the Newton iteration algorithm..." and "...we get (equation with "approximately equal to" featured prominently); use this as a first guess..." and finally "...we can see how the iteration drives successive approximations toward..." with warnings about techniques to use to keep the singularities in the equations from crashing your computer.

I mean, the problem obviously can be solved and answers obtained, but to the best of my knowledge nobody has ever succeeded in turning it into a closed-form "feed these parameters into this set of equations and here's the answer" sort of recipe. It's an iterative process that starts with a (literal!) guess and then looping back through the equations multiple times will make that guess successively closer to correct. And the math is sufficiently turgid, with enough seemingly-arbitrary variable substitutions, that I'm not sure I could even distill it down to a reasonably-tight set of equations which could be picked up and easily mechanized (even iteratively!) by someone else.

On the plus side, for what it's worth... the problem that's tripping you up here is one that also stumped Johannes Kepler, Sir Isaac Newton, Tsiolkovsky, von Braun... So you're in EXCELLENT company!

[grom]

I mean, the problem obviously can be solved and answers obtained, but to the best of my knowledge nobody has ever succeeded in turning it into a closed-form "feed these parameters into this set of equations and here's the answer" sort of recipe. It's an iterative process that starts with a (literal!) guess and then looping back through the equations multiple times will make that guess successively closer to correct. And the math is sufficiently turgid, with enough seemingly-arbitrary variable substitutions, that I'm not sure I could even distill it down to a reasonably-tight set of equations which could be picked up and easily mechanized (even iteratively!) by someone else.

On the plus side, for what it's worth... the problem that's tripping you up here is one that also stumped Johannes Kepler, Sir Isaac Newton, Tsiolkovsky, von Braun... So you're in EXCELLENT company!

Mmmm.. yes so far it seems using the RK4 iteration I have its not a bad solution then. Just need to clean up the code and add comments.

And I'm only dealing with orbits on the same plane. Have no idea how to take inclined orbits into consideration, other then simulate to where the inclined orbit passes over the launch site.

[grom]

It may be better to just rendezvous once in orbit. It's easier, but really you do want to get close after launch. I usually just eyeball it because I don't want to go through all that stuff with numbers at the moment...

Yes that is easier.. but also uses up deltaV. I originally started to work on this little simulator cause I was in situation where I had limited fuel. At the time I resorted to trail and error with quicksave/quickload and thought if only I had a calculator for this. It was quite an interesting situation.. I had to even use jetpack fuel to save Jeb.

[GoSlash27]

grom,

I'm sorry, but I'm having a hard time following what you're saying here in some parts.

The problem isn't figuring out when a launched rocket will intersect the orbit of a station, but rather figuring out how much time it takes for your rocket to achieve that orbit and where it will be when it does. This problem is compounded by the launch mode that you're using.

A highly- efficient ion glider might take most of an hour to achieve orbit and be on the other side of the planet when it finally does. A high thrust-to-weight rocket will only take a few minutes. Both examples require completely different flight profiles.

All you can do really is trial and error in sandbox until you get a feel for where the station needs to be at launch for that particular rocket.

Sorry,

-Slashy

[Jimbimbibble]

With most of my lifters I find that if the station is about 15-20 degrees behind the space center I can launch and rendezvous in no more than 1-2 orbits. In real life, they slowly phase in over a period of days. It took the shuttle 3 days to dock with the ISS.

[grom]

grom,

The problem isn't figuring out when a launched rocket will intersect the orbit of a station, but rather figuring out how much time it takes for your rocket to achieve that orbit and where it will be when it does. This problem is compounded by the launch mode that you're using.

All you can do really is trial and error in sandbox until you get a feel for where the station needs to be at launch for that particular rocket.

Sorry,

-Slashy

Hey Slashy, I value the input. Well my original situation I was dealing with was the Mun. But you are correct about launch profile. That is why I using an RK4 simulator. I program in a launch profile, the one I have at the moment is hell basic, but I can put it code for other launch profiles.

But the problem I was trying to solve with maths was once I find where I intersect the stations orbit, I know the current stations position. I want to then know the time difference it would be for the station to be in that intersection point from its current position. Or in other words.. Given two points in an orbit, calculate the time difference between them. Does that make sense now?

[maltesh]

http://integrals.wolfram.com/index.jsp?expr=sqrt%28l%2F%28GM%29%29x%2Fsqrt%28%28e^2-1%29x^2%2B2lx-l^2%29&random=false

l = semi latus rectum

e = eccentricity

x = distance between centers

I don't understand how to simplify this equation in order to convert it into code. So my aim is when I calculate the rocket will intersect the stations orbit that I use a formula to calculate the time it would take for the station to reach this position.

Wolfram Alpha is certainly going to assume that "e" in an equation is Euler's Number (2.7182818284...) , not a variable for eccentricity. Which is why the logarithms show up when you attempt to have Wolfram solve it.

Edit: No, I guess it's not the /only/ reason. Nevertheless, I've never encountered an online calculator that knew about Euler's number that didn't automatically substitute it whenever "e" showed up.

Edited December 21, 2014 by maltesh

[Srpadget]

Now, having gone on a while back about what a bear Kepler's Problem is to solve from a mathematical perspective, I'll let you know how I do it in KSP, good enough for the practical purpose of rendezvous with an orbiting station.

First: make sure your station is in a nigh-PERFECT circular orbit (I tend to do some fussy orbit adjustments of my LKO stations whenever I'm off-circle enough that the Ap and Pe don't 'dance' due to rounding errors, around Ap-Pe < 100 meters). (Genuinely circular orbits make all sorts of rendezvous-related tasks more straightforward.) Next, find your orbital period.

Now take advantage of the fact that circular orbits are a special case where you don't really need to go through all the hardcore math: your station's orbital speed is essentially constant. So if you know the time-to-orbit of your launcher, you know where your station needs to be at launch simply by noting the fraction of its orbital period consumed by your launcher's ascent. Easy-peasy.

But if for some reason your target is in a noticeably eccentric orbit, then yeah--I'm afraid an iterative process wrapped around an RK integration of the EoM is pretty much your best bet.

[Rook116]

Hey Slashy, I value the input. Well my original situation I was dealing with was the Mun. But you are correct about launch profile. That is why I using an RK4 simulator. I program in a launch profile, the one I have at the moment is hell basic, but I can put it code for other launch profiles.

But the problem I was trying to solve with maths was once I find where I intersect the stations orbit, I know the current stations position. I want to then know the time difference it would be for the station to be in that intersection point from its current position. Or in other words.. Given two points in an orbit, calculate the time difference between them. Does that make sense now?

Grom,

I hope I understand your problem, otherwise just ignore the link.

I think you are looking for transit time in a Hohmann transfer (http://en.wikipedia.org/wiki/Hohmann_transfer_orbit). This will work for moving from one orbit to another (I just did this for a satellite in a parking orbit and moving into a Keostationary orbit). However, due to atmospheric effects, the calculation gets more complicated when trying to time a launch from KSC. I usually just determine the time to reach a desired stable orbit with a specific build, then back calculate the orbital period for that altitude and determine the angular travel that my rendezvous point would make in that time.

Hope this helps.

[hypermetric]

Kepler's third law might be helpful then T1^2/T2^2 = r1^3/r2^3. I too have a copy of Fundamentals of Astrodynamics. I find I don't use it much as vanilla gameplay does not provide complete orbit elements. I takes no less than 6 numbers to fully define an unpeturbed obit. KSP usually doesn't provide more than 2. There might be someway to deduce the other elements using in game references points but I haven't figured it out.

[Rook116]

The persistent.sfs file has the orbital elements of any ship...

ORBIT

{

SMA = 8291050.81119871

ECC = 0.00553219673058219

INC = 87.7990597329687

LPE = 183.533727002483

LAN = 201.48070476959

MNA = 1.50049493127066

EPH = 230587.888000713

REF = 1

SMA : Semimajor axis – the average of the periapsis and apoapsis distances from the orbiting body center

ECC : Eccentricity – shape of the ellipse, describing how much it elongated compared to a circle.

INC : Inclination – vertical tilt of the ellipse with respect to the reference plane, measured at the ascending node.

LPE : Longitude of periapsis – horizontally orients the periapsis of the ellipse.

LAN : Longitude of the ascending node – horizontally orients the ascending node of the ellipse.

MNA : Mean anomaly at epoch – defines the position of the orbiting body along the ellipse at a specific time.

EPH : epoch – the reference time for the orbit.

REF : reference body – the ID of the body around which the orbit occurs. 0 is the sun, 1 is Kerbin, 2 is Mun, 3 is Minmus.

Also, see the link at the bottom of maltesh's post.

Edited December 24, 2014 by Rook116

[hypermetric]

Oh that will be very helpful for trip planning, thank you. Still though I was thinking about seeing this info in for whatever situation you are in. Any real space agency would be able to tell you at least that much about their spacecraft at any given moment. The game gives you altitude and speed in any situation (not velocity like it says, velocity would be vector and much more helpful). What the game should provide is declination and right ascension at least. Given those readings the orbit could be figured out. I don't know if there is a way to do it with just the altitude and speed. I suppose I could figure much of it out by waiting to reach ap or pe to record speed, but I don't think that will get me further than just the ap and pe altitudes alone do and wouldn't be much help in planning a landing. Though I suppose the lack of info the game provides forces you to get a feel for it, I wish more info was there even as a cheat or something.

[taio]

MechJeb provides the orbital elements. KER or VOID might too, but I forget. Certainly they provide some of them.

[Tripzter]

Eye ball the launch, if you end up ahead of it, go in higher orbit, if you end up behind it go in low orbit.

[maltesh]

Oh that will be very helpful for trip planning, thank you. Still though I was thinking about seeing this info in for whatever situation you are in. Any real space agency would be able to tell you at least that much about their spacecraft at any given moment. The game gives you altitude and speed in any situation (not velocity like it says, velocity would be vector and much more helpful). What the game should provide is declination and right ascension at least. Given those readings the orbit could be figured out. I don't know if there is a way to do it with just the altitude and speed. I suppose I could figure much of it out by waiting to reach ap or pe to record speed, but I don't think that will get me further than just the ap and pe altitudes alone do and wouldn't be much help in planning a landing. Though I suppose the lack of info the game provides forces you to get a feel for it, I wish more info was there even as a cheat or something.

With altitude, speed, and pitch angle, (and knowing the gravitational parameter and the radius of the object you're orbiting), you can figure out the shape of your orbit, and where you are on that orbit, and travel times to arbitrary points on that orbit. I wound up writing a program to do that back in the 0.8-ish era before there was a map screen. That said, it diesn't help much with rendezvous, as that info doesn't tell you how your orbit is aligned in space, and not uch with landing, as it doesn't tell you how the world below you is spinning.