Math, KSP Calculators Questions

[ScrapIron]

I'm very new to the community, but very thankful already to all of the great posts, mods, and calculators. I particularly like the calculators that folks have developed, and I'm wondering if anyone has more detailed knowledge about the actual mathematics. It seems the calculators are using approximations, which is understandable since the math gets tough quickly without them. Specifically, I've been looking at planetary phase angles. Olex's (https://ksp.olex.biz/) calculator and KSP wiki (https://wiki.kerbalspaceprogram.com/wiki/Time) both report that the optimal phase angle for transfer is 44.36 degrees. I can derive this value, but I don't think it's technically correct, and that it could vary, say, between 38-53 degrees. Can anyone discuss this?

-Also, I apologize if I'm posting in the wrong place.

[VoidSquid]

Hi and welcome, @ScrapIron,

Wow, I'm impressed, you certainly are a very smart person (much smarter than me anyway)  

Guys coming to my mind immediately here are definitely @sarbian , @Jim DiGriz and the other folks developing MJ, see this thread

 

 

[Jim DiGriz]

Lambert solvers.

In the simplest case, neglecting the planetary orbits and only looking at the heliocentric problem you have three orbits and two unknowns.  One is the coast to your departure time, which is determined by the departure planet's orbit.  The last is the coast to the arrival time, which is determined by the arrival planets orbit.  To figure out the transfer orbit from the departure position and time to the arrival position and time you use a Lambert problem solver.

MechJeb actually has two.  I think this one is Battin's method:

https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/LambertSolver.cs

This one is Gooding's Method:

https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/GoodingSolver.cs

I think the Gooding one is robust enough now that the former could be deleted, although I haven't fully tested the multi-revolution behavior of the Gooding Solver yet.

Anyway.

Now given the departure and arrival times you can solve the problem for how much delta V it costs for the departure burn and for the arrival burn (unless you're not going to match orbits and are going to do an impactor or a flyby).

The problem then becomes searching for departure and arrival times which minimize the cost of the transfer orbit.  You can brute force search that and that is what produces a porkchop plot.  Or you can turn it into a minimization problem and use off-the-shelf algorithms to find the minimum value.  Newton's method is the Calculus 101 tool that can be used to solve that problem, but since derivative information is difficult to obtain for the problem, its better to use some kind of quasi-Newtonian solver like Levenburg-Marquardt.  For finding global solutions to the optimization problem that is harder and is the domain of simulated annealing or basin hopping algorithms.

Edited November 24, 2019 by Jim DiGriz

[ScrapIron]

Ok, thanks for confirming my suspicions. I've developed an algorithm for non circular transfers. The basic mechanics is relatively simple, alg-trig formulas, but there's no way to solve the system of 5-6 equations I get. The transcendental trig functions make it so. Time gets a little complicated, too. The orbiting craft has to travel partly around its orbit, and then around the rendezvous ellipse. This time has to match the time of the target in orbit. The series expansions relating time and true anamoly, or numerical integration (which is just a simple series with lots of terms) work. 

My process has been this: given the positions of orbiter and target, determine where the orbiter burns and with what delta-v. I choose a position ahead of the orbiter in increments, then choose increments in delta-v for each position to determine an ellipse that just touches/intersects the target ellipse. Then, check the time of flight of both objects. If times match (are close), then done. 

I've tried working tangents (derivatives of polar positions) into the problem, but that fails because equal tangents don't insure intersection. 

Anyway, I've got an iterative procedure that working. I was just wondering if anyone else here has attempted this, and it seems so. There's supposedly a third degree differential equation that's really efficient at getting the solution. I've read a little about the Lambert problem, but I was trying to solve the problem myself, from scratch; just basic principles. 

Another note, too. Excel sucks for this type of heavy-duty number crunching. I had to put in error catches because dumb excel truncates floating point numbers due to its rudimentary bit scheme. Have to do this in a real math language. 

I've enjoyed solving this problem by myself, with only basic principles (mechanics, etc.). Now that I've done it, I'm curious to see what other folks have done. I'm relieved too, to know the solution is not closed form (trivial). The drawback of working alone is the almost insane, or obsessed state it can put a person in. I imagine this is how some of the pioneers felt at times, Kepler for sure. Thank you for responding, and thank you for the links. Very appreciated!

[HebaruSan]

On 12/16/2019 at 8:26 AM, ScrapIron said:

My process has been this: given the positions of orbiter and target, determine where the orbiter burns and with what delta-v. I choose a position ahead of the orbiter in increments, then choose increments in delta-v for each position to determine an ellipse that just touches/intersects the target ellipse. Then, check the time of flight of both objects. If times match (are close), then done. 

I've tried working tangents (derivatives of polar positions) into the problem, but that fails because equal tangents don't insure intersection. 

Anyway, I've got an iterative procedure that working. I was just wondering if anyone else here has attempted this, and it seems so. There's supposedly a third degree differential equation that's really efficient at getting the solution. I've read a little about the Lambert problem, but I was trying to solve the problem myself, from scratch; just basic principles. 

Hi @ScrapIron, welcome to the forum and thanks for posting this topic. It's giving me flashbacks to developing Astrogator!

My strategy was similar, but I think I used less sophisticated math than you did. I use the bisection method to minimize the difference in "phase angles" (probably not a proper use of the term but hopefully you can intuit the meaning) at time of arrival, since those values dropped out most naturally from the calculations I was able to figure out:

https://github.com/HebaruSan/Astrogator/blob/60cd8c74b72bc0436e4f7a5a0cb7e7ec67887c20/src/PhysicsTools.cs#L305-L324

Anyway, I'm very interested in your work, I suppose for the selfish reason of wanting to learn and improve my mod. If you have any suggestions for code improvements, I'm all ears!

[pmborg]

On 11/3/2019 at 2:58 AM, ScrapIron said:

I'm very new to the community, but very thankful already to all of the great posts, mods, and calculators. I particularly like the calculators that folks have developed, and I'm wondering if anyone has more detailed knowledge about the actual mathematics. It seems the calculators are using approximations, which is understandable since the math gets tough quickly without them. Specifically, I've been looking at planetary phase angles. Olex's (https://ksp.olex.biz/) calculator and KSP wiki (https://wiki.kerbalspaceprogram.com/wiki/Time) both report that the optimal phase angle for transfer is 44.36 degrees. I can derive this value, but I don't think it's technically correct, and that it could vary, say, between 38-53 degrees. Can anyone discuss this?

-Also, I apologize if I'm posting in the wrong place.

Hello,

In my opinion the best way to learn the Math for this orbital mechanics is write our own programs to be used in KOS.

Trying to do a mission 100% full auto-pilot:

• - go on kerbin orbit
• - do a circular orbit
• - go to mun
• -land on mun
• -return to orbit
• -land on kerbin

then to do inner planet and into an outer planet and so on...

 

Edited December 17, 2019 by pmborg

[Maxsimal]

On 11/3/2019 at 2:58 AM, ScrapIron said:

I'm very new to the community, but very thankful already to all of the great posts, mods, and calculators. I particularly like the calculators that folks have developed, and I'm wondering if anyone has more detailed knowledge about the actual mathematics. It seems the calculators are using approximations, which is understandable since the math gets tough quickly without them. Specifically, I've been looking at planetary phase angles. Olex's (https://ksp.olex.biz/) calculator and KSP wiki (https://wiki.kerbalspaceprogram.com/wiki/Time) both report that the optimal phase angle for transfer is 44.36 degrees. I can derive this value, but I don't think it's technically correct, and that it could vary, say, between 38-53 degrees. Can anyone discuss this?

-Also, I apologize if I'm posting in the wrong place.

Phase angle between two perfectly circular 0 inclination orbits w/Keplerian orbital motion shouldn't be a range, there's an exact value that you can get to analytically for a simple Hohmann transfer. Kerbin's is perfectly circular, and Duna's is nearly so.  I believe that calculator is narrowing the problem down by assuming Duna's is as well.   

However, even if you did use Duna's real orbit rather than assuming it's circular, I don't think the range would be that wide - transfers to other bodies with more eccentric/inclined orbits though, you're right, it would be a wider range, and dependent on which orbit you're looking at.  If you notice, neither of those places mentions which Kerbal date you should depart from/asks you for which Kerbal date to search from.

[Jim DiGriz]

On 12/17/2019 at 12:31 PM, HebaruSan said:

Hi @ScrapIron, welcome to the forum and thanks for posting this topic. It's giving me flashbacks to developing Astrogator!

My strategy was similar, but I think I used less sophisticated math than you did. I use the bisection method to minimize the difference in "phase angles" (probably not a proper use of the term but hopefully you can intuit the meaning) at time of arrival, since those values dropped out most naturally from the calculations I was able to figure out:

https://github.com/HebaruSan/Astrogator/blob/B60cd8c74b72bc0436e4f7a5a0cb7e7ec67887c20/src/PhysicsTools.cs#L305-L324

Anyway, I'm very interested in your work, I suppose for the selfish reason of wanting to learn and improve my mod. If you have any suggestions for code improvements, I'm all ears!

For root finding on a line you should look at  Brent's method:

https://en.wikipedia.org/wiki/Brent's_method

Or the brent.m file here:

https://www.mathworks.com/matlabcentral/fileexchange/73600-trans-lunar-trajectory-optimization-otb-version

For N-dimensional root finding Levenburg-Marquardt is the next step up, C# code can be found here:

https://www.alglib.net/optimization/levenbergmarquardt.php

Or Matlab's fsolve:

https://www.mathworks.com/help/optim/ug/fsolve.html

[HebaruSan]

4 minutes ago, Jim DiGriz said:

For root finding on a line you should look at  Brent's method:

https://en.wikipedia.org/wiki/Brent's_method

Or the brent.m file here:

https://www.mathworks.com/matlabcentral/fileexchange/73600-trans-lunar-trajectory-optimization-otb-version

For N-dimensional root finding Levenburg-Marquardt is the next step up, C# code can be found here:

https://www.alglib.net/optimization/levenbergmarquardt.php

Or Matlab's fsolve:

https://www.mathworks.com/help/optim/ug/fsolve.html

Hmm, what improvements would these give? I don't think the bisection method is causing me any problems currently; it finds the roots, and it's fast enough. I was thinking more along the lines of improvements in the equations being solved, ideally for greater accuracy.

[Jim DiGriz]

Generally its better to approach the problem as an optimization problem rather than a system of equations to be solved.  So use an off the shelf solution to the Lambert problem, wrap that with your source and destination orbit propagators (e.g. Orbit.GetOrbitalStateVectorsAtUT ) and pose the problem as a minimization problem of finding the starting time and ending time (or duration) of the transfer that minimizes the deltaV.  To do that you have a 2 dimensional root finding problem with two variables (start and end time).  Feed that into Levenburg-Marquardt and you should get an accurate result.  Of course the problem is a global optimization problem with many local minima (all the upcoming transfer windows) so you need to feed it an initial guess.  That's enough to do a simple helocentric solver.

You can also do a solver that uses KSP's Orbit class to propagate orbits using the actual in-game patched conics API.  In which case you can adopt a "shooting method" where the time and 3-vector of the burn can be optimized, and then you propagate to find the point of closest approach to the target orbit.  Then wrap that with Levenburg-Marquardt, although its a bit tricky since you want to minimize the delta-V of the burn while keeping the final orbit nearly intersecting the target.

A lot more clever things can then be done by replacing Levenburg-Marquardt with an NLP solver like ipopt or Matlab's fmincon, to do constrained nonlinear optimization, but that is also much more complicated.

Edited December 21, 2019 by Jim DiGriz

[Retro Starship]

 

Welcome to the KSP forum @ScrapIronSorry for the late welcome. Always try to check out new members but get cough up on so many other topics. New here myself by a few months. Love KSP, so much fun.