Kerbal Space Program Trajectory Optimization Tool

[Nadrek]

Relating to TOT itself, in version 0.3 I didn't see an easy way to launch from, say, Minmus (or an arbitrary orbit), and then use Kerbin to give a grav assist to another body ouside the Kerbin system (say, Eve).

Is this a lack in the interface, or a lack in my understanding of orbital dynamics?

[togfox]

Should I be critiquing the "Optimizer" yet? Looks good - I'm not sure what trajectory it's optimising though. That tab doesn't say.

[Arrowstar]

Should I be critiquing the "Optimizer" yet? Looks good - I'm not sure what trajectory it's optimising though. That tab doesn't say.

Sure, if you'd like. The basic functionality is there, if you want to use it. Comments on usability and whatnot would be welcome.

Relating to TOT itself, in version 0.3 I didn't see an easy way to launch from, say, Minmus (or an arbitrary orbit), and then use Kerbin to give a grav assist to another body ouside the Kerbin system (say, Eve).

Is this a lack in the interface, or a lack in my understanding of orbital dynamics?

Okay, so the functionality you're asking for is probably not going to be in for a long time. What you're asking for involves changing central bodies twice. The first involves leaving Minmus, and the second involves leaving Kerbin. The former isn't too bad because Minmus is orbiting Kerbin. However, the latter is challenging given the standard assumptions of the two-body model. It's not the forward computations that are hard, mind you. It's the fixation of the end conditions: how do you specify an orbit that starts on Minmus and ends at Eve while swapping spheres of influence? I've been thinking about this for a long time and I don't have an answer yet. Hopefully I'll get into this problem after the basic functionality is there.

[togfox]

I had a thought : if your prog uses "universal time" (time from zero hour) along the axis, but we cant actually determne what the cureent universal time is (in version 0.16), how are we going to know when to launch to hit the next pork chop?

One 'hack', for those that care enough, would be to start a new persistence file and immediately land (or drive a cart) a pod just off the side of the pad (or anywhere convenient) and leave it there forever. The MET for that pod essentially reflects universal time if the launch is done quicky (it might be out by a few minutes) and if you need to deermine universal time then go to the tracking station to see the MET on that pod. You could name the POD as UTC or something meaningful (Kerbin Mean Time - KMT)

[Arrowstar]

That would work. Ideally, either KSP or (failing that) MechJeb could provide a Universal Time clock. In the latter, it could probably be placed in the Orbit Info panel or in a new panel. In the former (native KSP), it could perhaps be placed under the MET counter or something.

In any event, it's not really a problem with KSP TOT, though I agree it makes it harder to use. I'll petition either the devs or r4m0n to look into a solution that would be helpful. Thanks for bringing this up, togfox!

[wonderwhale]

I don't understand the charts, but it looks great!

[Nadrek]

Relating to "I didn't see an easy way to launch from, say, Minmus (or an arbitrary orbit), and then use Kerbin to give a grav assist to another body ouside the Kerbin system (say, Eve)"

Okay, so the functionality you're asking for is probably not going to be in for a long time. What you're asking for involves changing central bodies twice. The first involves leaving Minmus, and the second involves leaving Kerbin. The former isn't too bad because Minmus is orbiting Kerbin. However, the latter is challenging given the standard assumptions of the two-body model. It's not the forward computations that are hard, mind you. It's the fixation of the end conditions: how do you specify an orbit that starts on Minmus and ends at Eve while swapping spheres of influence? I've been thinking about this for a long time and I don't have an answer yet. Hopefully I'll get into this problem after the basic functionality is there.

I agree that this isn't something that works within the two body model. However, given that you've worked out an iterative solution already, what about a nested iterative solution? I.e calculate a spread of two body problems (say, the end first - going to Eve), and then for each of those, calculate a spread of two body problems (say, the beginning - using Kerbin as a grav assist). Determine the aggregate best out of the spread, and then iterate a new spread around that. Or whatever other iterative technice is preferred, of course; this was merely a poor example.

[Arrowstar]

So yeah, I've actually considered that. Say you were on the Mun and wanted to get to Bop, a moon of Jool. Basically what you'd do is run the high-level trajectory first (say, Kerbin to Jool). Then you'd have to compute Kerbin-centric trajectories that enforce the outbound hyperbolic velocity vector from the high-level trajectory. You'd do the same for the Jool-centric trajectory.

Now, here's the big problem. When you get to Jool's SOI, your target is Bop. And you know your inbound hyperbolic velocity vector as well. So you should have enough information to fix an orbit (a position and a velocity), but I haven't worked out how yet because those vectors are valid at different times. You'll have the same problem leaving Kerbin's SOI. Your departure point might be the Mun, and you know your outbound hyperbolic velocity vector, but how to resolve that into an orbit is a challenge.

Anyway, let me perfect the single-SoI flight plan stuff first and then I can upgrade to an iterative process as you've suggested.

[Arrowstar]

I don't understand the charts, but it looks great!

Can I help clarify anything? What are you confused about?

[sanity]

what information can be determined by usuing the chart?

how do you read it?

[Arrowstar]

The bottom axis is the time at which you depart. The left axis is the time at which you arrive. The intersection of lines extending off those axes tells you either A) how much energy is required to get to your destination, or the speed at which you arrive at your destination (which you have depends on what analysis you choose to do). The higher the quantity, the more fuel you need. The "optimal" departure and arrival times will be at the low points in the plot.

Does that help?

[sanity]

excellent cant wait for 0.17 so i can put it to good use!

[khearn]

I'm giving this a spin on a Linux system. Once I told it to use a 1.7 version of java it seems to work. It looks really useful, once I figure out how to use it. Below are a number of things I've noted. Please take them as constructive criticism. I like what you're doing and I hope my feedback will be helpful.

First thing to note is that some of the UI elements need tweaking.

The labels for the data fields get buried under the fields for the Semi-major axis through the Right Asc. of Asc. Node. Also, the units on the right side don't have enough space.

Now, a bug report:

I first set up a flight plan that started in Kerbin orbit, did an assist around Eve, and returned to Kerbin (not the plan show in the above screenshot). Then I ran the optimizer without changing the default settings. It gave me an error about the population size being bad for the algorithm. I apologize for not remembering the exact error message. I know how much less a bug report is worth without it. So I changed the algorithm to "Standard Genetic Algorithm" (was originally "TRIBES Adaptive Particle Swarm Algorithm") and it worked. The default population should probably be something that works with the default algorithm.

It would also be nice if it gave a better indication that it's working. The optimize button went gray, but I wasn't sure if it was doing something or just freezing up until it displayed the results. An activity bar would be nice (or even better a progress bar if the algorithm is such that you can show how far along it is), but even just displaying something like "Performing the optimization" would be helpful.

<del>Then I went to the "Energy and Velocity Analysis" and got told I can't do that if my origin and destination are the same. (again, I didn't save the exact message, sorry). It seems like I ought to be able to do so for a flight that starts at Kerbin, does a tour, and comes back. </del> Nevermind, I just realized that the Energy and Velocity Analysis tab doesn't seem to use the flight plan at all. That wasn't obvious. I'm not sure how to make that clear to the user. Or maybe it just needs a brighter user. :-/

So anyways, I went back and set up a flight that starts at Kerbin and goes to Eve, with no gravity assists, as shown in the above screenshot. Just an INITIAL and an ENTERORBIT. Then I went to the optimizer and ran it, and got this result:

It seems to be showing me a flight the starts at Kerbin, does a fly-by of Eve, does a fly-by of Kerbin, and then arrives at Eve. At least that's what it looks like to me. I suspect that it didn't properly clear out the data from my original flight plan when I changed it to the new one, even though the UI showed the changes.

Also note that the "Optimize Trajectory" button is on top of the Algorithm pulldown.

One question about the Energy and Velocity Analysis. It mentions Type I and Type II transfers, but doesn't say what they are. Are they what are also known as opposition class and conjunction class transfers? If so, which is which?

Thanks for making this. It does look like it will be quite useful.

[togfox]

Update please.

If there were a cfg file we could update with our own data.

I hope you continue this hard work!

[Arrowstar]

H'okay, so, basically over the past 6 months I've been asked a few times to continue this work. I haven't really had the desire lately, mostly because the original application was in Java and I was writing literally everything from scratch. Not fun. Sunday, however, I had a minor epiphany and decided to jump back in, but to do it in MATLAB (which will be compiled into a Windows executable later).

I thus present: KSP Trajectory Optimization Tool (Mk II)!

I literally started writing this yesterday (Monday), which is why it looks pretty unfinished. However, the basic functionality is there. You select a departure body, the body to arrive at, and some start time offsets, and it computes delta-v.

Q: How is this different than those "Phase Angle Calculators" I see all over the internet?

A: KTOT2 uses a fairly sophisticated Lambert solver I have (see, for example, the MechJeb Lambert solver, which is basically my code) to accurately compute transfer orbits regardless of the nature of the orbits of the departure and arrival bodies. There are no wildly inaccurate assumptions made about orbit circularly, co-planar-ness, or the like.

Ultimately I'd like for the tool to spit out a report detailing the best transfer orbit based on departure ÃŽâ€V, arrival ÃŽâ€V, or their sum. In addition, I've worked out the math for computing the burn location and magnitude (the ÃŽâ€V vector) from your starting body given an orbit about it, so that should be useful for creating maneuver nodes in KSP.

I need to know two things from people before I keep going on this:

1) Useful? Would you use it?

2) What features do you want to see beyond what I've listed above? I really could use some ideas here.

Oh... should I start a new thread, given that this is a whole new application?

[Fyrem]

Arrowstar,

while you were out, someone else did this : http://forum.kerbalspaceprogram.com/showthread.php/33023-WEB-APP-Launch-Window-Planner

perhaps you two can work together?

[Arrowstar]

Thanks for the link! I noticed that his tool still assumes that you're in a circular, co-planar orbit about the departure or destination body. I plan on being much more flexible: specify your current orbit (or one day, get it directly from the game) and your desired orbit about the final body and it'll literally tell you where to put the node (at what time) and in what direction to point it. Heck, I'll even have it draw pretty pictures.

I worked out the final remaining bit of math tonight, and I should have a bit of time to continue this week.

Still looking for more responses to my questions... if anyone has any thoughts, please let me know.

[Splode]

YES PLEASE.

This would be a brilliant tool. I'm glad this will run externally to KSP, it will be perfect for mission control set ups.

This and telemachus, oh man.

[Mekan1k]

You should work with MechJeb- This mod, plus mechjeb, and the launch-window planner, has the makings of a brilliant autopilot.

[Arrowstar]

So I've made some progress today on the mathematics side. Between yesterday and today I've fully worked out the mathematics for computing the departure body-centric delta-V required to achieve any transfer orbit to anywhere in the Kerbal solar system.

Basically, given:

1) A starting orbit around a planet/moon, and

2) A transfer orbit around some "central body" (say the Sun or Jool)

my code will now compute the required delta-v vector required to achieve the transfer orbit about the central body.

As an example, take a hypothetical Kerbin departure to some other planet, say Jool. You start in the following orbit about Kerbin:

SMA = 1700 km

Eccentricity = 0.2

Inc = 11.5 deg

RAAN = 5.7 deg

Arg of Peri = 5.7 deg

Using the first part of my tool (the porkchop plot tool, above, which will actually just use this information transparently to the user, but bear with me...), you know you want to hit of hyperbolic excess velocity of:

V_inf_outbound = <0.5, 0.4, 0> km/s

My code does some math and comes up with the following optimal departure (that is, it's not any departure orbit, it's the least expensive (aka best) you can achieve!):

(Solid black line is the current orbit about Kerbin, the dashed line is the hyperbolic escape orbit, and the cyan line at the intersection of the two is the delta-v vector.)

What this says is that if you burn 0.55193 km/s in your velocity direction, -0.76105 km/s in your orbit normal direction, and 0.35743 km/s in your radial direction, you'll hit your target escape orbit and be on your way to Jool! The code also knows the burn true anomaly, making it easy to place the maneuver node.

I realize these numbers don't mean much unless you use MechJeb or Improved Maneuver Nodes. However, if you do use these tools, all you have to do is create a maneuver node at the correct location, enter these values into the boxes, and execute the maneuver. Voila! You're basically where you want to be.

I need to talk to The_Duck and R4mon and see if they'll do a "create node at True Anomaly" thing for MechJeb. If they can, this will be a hundred times better for use in-game. As it is, though, it's an excellent planning tool.

Any thoughts, comments, etc? Please note that what I'm showing is just the math and I still need to work out a GUI, etc, for actually applying it.

Edited June 6, 2013 by Arrowstar

[Arrowstar]

Just a heads up, folks, that I've put out an initial release version over at: http://forum.kerbalspaceprogram.com/showthread.php/36476-WIN-KSP-Trajectory-Optimization-Tool

Development work and discussion will continue there, and this thread is effectively closed now (though I'd like it to formally remain open) (it was getting too old and too big for my own good ).

[Fyrem]

Great! I will check it out asap.

(did you get any response from Mechjeb author?)

[Arrowstar]

Great! I will check it out asap.

(did you get any response from Mechjeb author?)

Sadly I did not, no. Not for lack of trying, though.

By the way, Fyrem, could you continue any discussion or posting you might do over on the new thread I linked to in post 96? That'd be awesome. Thanks!