[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[Arrowstar]

Hi dude, I was wondering if you have time to craft a little tutorial for gravity assists, using this little wonder of yours

Thanks for your time!

Hi Iron! Thanks for using KSP TOT. I could, but it would probably take me a while. Might be faster for you to simply post what questions you have and I can answer them that way. It should be a fairly straightforward application to use: select your starting body, your fly-by body, and your arrival body, along with the time range you want to look at fly-bys over, and push go. Go get a cup of coffee or something, it usually takes a few minutes.

That question reduces to, can you formulate the problem in such a way that the objective function and constraints are differentiable? Logic and switching could make that rather complicated, but it depends on the specifics of the objective and constraint functions. If you can write Matlab code to evaluate them in the first place, then you should have enough information for an automatic differentiation library to do the rest of the work. It's not something I would try to do symbolically, I would use an AD library. For C++ ADOL-C and CppAD are very good, I'm not so sure if there are any good open-source tools for doing the same thing entirely within Matlab. This page http://www.i2c2.aut.ac.nz/Wiki/OPTI/index.php/Advanced/Deriv1 looks like a pretty good reference on the topic. I'll frequently use Matlab or Python to put the problem together in the first place but then output an optimization problem representation that a compiled solver can read and do AD on - either OSiL which is XML-based, or .nl which is used by AMPL and not really human-readable (but Pyomo knows how to write them).

Your mention of automatic differentiation is intriguing, but I can't say I'm very familiar with it. Can you describe what it is and how it would be useful here? I'm all for any suggestions that improve the efficiency of my code.

Sure, go for it. Some test inputs would help too, I imagine you already know where the bottlenecks are and what's most important to look at.

Alright, will do, thanks! I'll provide some test inputs and outputs in a text file for you to use.

@ArrowStar, this has probably been asked before but I haven't kept up to date with the forums at all:

Would your TOT for Orbiter work for Real Solar System? Does it take into account N-Body physics and such?

TOT for Orbiter is not appropriate for KSP, sorry. It does use full n-body physics in some places and that would likely screw up things. Your best bet is to create a new bodies.ini file based on the example I provide in the KSP TOT release and go from there. Work with the author of Real Solar System to get the orbit and size information you need.

[Arrowstar]

Just a heads up, guys, I've uploaded a new pre-release build (same link above). It includes the following:

• A fix to a bug with bounds in the optimizer code;
  
• Addition of a "view state at event" feature;
  
• Addition of the "Advance script to event" feature
  
• State readouts now have tooltips
  

The first item, the bug, was the main reason for this update coming out so fast, but the other features are nice, too. Please re-download at your convenience.

Edited February 9, 2014 by Arrowstar

[diomedea]

Hi Arrowstar,

tried your pre-release build (the new version), it works. Fascinating.

But, I hope you will provide some more detailed instructions on how to use Mission Architect. I give it some simple events (like a prograde burn), sometimes it updates the final state accordingly, sometimes goes crazy. It seems it expects some conditions, while others don't work (therefore, should be better to restrict input to only the ones valid). E.g., after a prograde burn, if I input to coast until a set true anomaly, it doesn't work; it works if I coast to apoapsis.

Also, the graphical display seems to update only with coast maneuvers.

About the optimizer (it IS FAST, less than 3 sec. x iteration): sometimes it finds a solution in very few cycles, sometimes it continues forever, with a maximum constraint violation <> 0 and both it and the function value not changing between iterations. Some hints on how to help the optimizer in these cases would be welcome.

[Arrowstar]

But, I hope you will provide some more detailed instructions on how to use Mission Architect. I give it some simple events (like a prograde burn), sometimes it updates the final state accordingly, sometimes goes crazy. It seems it expects some conditions, while others don't work (therefore, should be better to restrict input to only the ones valid). E.g., after a prograde burn, if I input to coast until a set true anomaly, it doesn't work; it works if I coast to apoapsis.

I think I know what's doing this, but to confirm, can you respond with the warning message you get in the lower right corner? If it's what I think it is, should be easy to fix. Feel free to post a link to a MAT file that you save with the mission and warning in it. That'll help me pinpoint the issue, too.

Also, the graphical display seems to update only with coast maneuvers.

This is by design. Only coasts have finite durations, so only they show up on the orbit display. Maneuvers, mass dumps, and the like are all instantaneous. There's nothing to show on the display. Hope that makes sense.

About the optimizer (it IS FAST, less than 3 sec. x iteration): sometimes it finds a solution in very few cycles, sometimes it continues forever, with a maximum constraint violation <> 0 and both it and the function value not changing between iterations. Some hints on how to help the optimizer in these cases would be welcome.

This is because the solution *is* changing, but it's so small that you can't see it in the display. It's just a tolerances thing for termination. If you cancel, you'll be offered a choice to keep the current solution as it's been found so far, so you won't lose anything. I need to rename that button to "Stop" or something like that. In any event, I'll play with the tolerances some today. Glad to hear it's fast, btw!

[diomedea]

I think I know what's doing this, but to confirm, can you respond with the warning message you get in the lower right corner? If it's what I think it is, should be easy to fix. Feel free to post a link to a MAT file that you save with the mission and warning in it. That'll help me pinpoint the issue, too.

Did the test again, but either I am getting a better feel with MA, or I made some error before. Coasting to a set true anomaly now works.

Did not test any possible conditions, so can't exclude some improvements can be done, but so far, really good and promising.

Anyway, if some conditions are plain wrong or inapplicable in a given situation, I would like those to be filtered and not allowed: in a sample case, I tried to put a coast to anomaly=0 while the state was already at anomaly=0: that means a "null" maneuver, but there is no warning and it is taken as good.

About the drawing, yes, makes sense. Indeed MA can't consider (yet) burns of finite duration instead of instantaneous, also I expected the burns to be shown with the predicted trajectory after the burn (as KSP does), while for me the idea of the coast maneuver was equivalent to letting time pass. But MA is right to show things this way.

[Arrowstar]

Did the test again, but either I am getting a better feel with MA, or I made some error before. Coasting to a set true anomaly now works.

Interesting. Well, I think I've actually fixed the root issue and a new build will be up shortly. Please let me know if the issue persists there.

Did not test any possible conditions, so can't exclude some improvements can be done, but so far, really good and promising.

Anyway, if some conditions are plain wrong or inapplicable in a given situation, I would like those to be filtered and not allowed: in a sample case, I tried to put a coast to anomaly=0 while the state was already at anomaly=0: that means a "null" maneuver, but there is no warning and it is taken as good.

So I suppose it's really a difference of philosophy. To me, if you say "go to true anomaly of 0" and then say it again, the code should do it once, then realize it's already there, and just return the same state. It's not an issue from a propagation perspective, it just means you have a redundant event. I'd hate for the application to throw an error that could kill an optimization process because of something that still works (even if it's a bit strange, as in the example you said).

Now that said, if you have any other examples where things *should* throw an error because they'd present issues with propagating the orbit, then I'm all ears. I need to know about those so that I can fix them.

About the drawing, yes, makes sense. Indeed MA can't consider (yet) burns of finite duration instead of instantaneous, also I expected the burns to be shown with the predicted trajectory after the burn (as KSP does), while for me the idea of the coast maneuver was equivalent to letting time pass. But MA is right to show things this way.

Good to hear!

[Arrowstar]

Hi everyone,

The pre-release build of v0.12 has progressed to #2. The second build is located here and features the following changes:

• Bug fix for coasting to true anomalies while in a hyperbolic orbit (diomedea's bug);
  
• A new "split coast at UT (universal time)" feature, it divides up coasts into two parts at a particular point in time;
  
• Some enhancements to the way that optimization parameters are stored and retrieved;
  
• Lots of tooltips everywhere;
  
• In the optimizer viewer, "Cancel" has been replaced with "Stop" and tooltip text has been added to describe what stopping does (namely, stop the optimization and return the current result).
  
• A few other minor things.
  

Let me know what you guys think! We're nearing full release status, I believe.

[diomedea]

Ok, I seem to be finding all the weirdest things.

I did try one thing, first using KSPTOT to find a transfer window (I am looking for a transfer from Kerbin to Eve), then using the same data that KSPTOT provided as input events for MA (both initial state and burn).

I would have expected the final state to be the same, instead the trajectory around the Sun shows to be quite different; of course I don't even expect MA to find Eve at the end of that different trajectory. No optimization run with MA, as it wasn't needed with the transfer trajectory.

I took some screenies of KSPTOT and the mission plan from MA, bundled here for you to see. I can't find errors on my part, but clearly I have not enough knowledge with KSPTOT or MA to exclude any.

[tavert]

Your mention of automatic differentiation is intriguing, but I can't say I'm very familiar with it. Can you describe what it is and how it would be useful here? I'm all for any suggestions that improve the efficiency of my code.

I'm not an expert in all the finer implementation details of how automatic differentiation works, but essentially given the source code of some complicated nonlinear function, automatic differentiation can calculate the numerical gradient of that function at a given input point with roughly the same complexity as computing the function value. There are different methods, forward mode is good for functions with a higher-dimensional output than input, reverse mode is good for functions with a higher-dimensional input than output. Then there are different types of implementation, commonly based on either operator overloading or source code transformation. The result will be much more accurate and much more efficient calculation of gradients than naive finite differencing, which results in faster convergence of an optimization algorithm.

[Arrowstar]

Ok, I seem to be finding all the weirdest things.

I did try one thing, first using KSPTOT to find a transfer window (I am looking for a transfer from Kerbin to Eve), then using the same data that KSPTOT provided as input events for MA (both initial state and burn).

I would have expected the final state to be the same, instead the trajectory around the Sun shows to be quite different; of course I don't even expect MA to find Eve at the end of that different trajectory. No optimization run with MA, as it wasn't needed with the transfer trajectory.

I took some screenies of KSPTOT and the mission plan from MA, bundled here for you to see. I can't find errors on my part, but clearly I have not enough knowledge with KSPTOT or MA to exclude any.

Ah, okay, so you've hit upon the difference between Mission Architect and the rest of KSP TOT. MA accounts for sphere of influence changes, everywhere else does not. It turns out that doing so is actually important and means you need to adjust your trajectory to account for it.

Here's what you do. Use the optimizer as a "targeter" by minimizing the distance to Eve, using the main part of KSP TOT has the initial guess, as you've done. Do so first without any constraints and let it plow you right into the planet. Then, once you're headed into Eve's SoI, add constraints on radius of periapsis and inclination. Once you've got that licked, then add any maneuvers at Eve.

You have to optimize in stages. Let the optimizer get you to where you're going with no constraints. Then slowly add constraints and maneuvers until you get the mission you want. And keep in mind that "optimization" is just a fancy way of saying "achieving a goal." Want to go somewhere? That's a goal. Want to minimize prop usage? That's a goal. All the optimizer does is achieve those goals.

Oh, last tip: as of pre-release #2, you don't need the coast to the edge of Kerbin's SoI. Just make it a coast to Eve's periapsis and once the optimizer gets you in the SoI, you'll go there no problem.

I'm not an expert in all the finer implementation details of how automatic differentiation works, but essentially given the source code of some complicated nonlinear function, automatic differentiation can calculate the numerical gradient of that function at a given input point with roughly the same complexity as computing the function value. There are different methods, forward mode is good for functions with a higher-dimensional output than input, reverse mode is good for functions with a higher-dimensional input than output. Then there are different types of implementation, commonly based on either operator overloading or source code transformation. The result will be much more accurate and much more efficient calculation of gradients than naive finite differencing, which results in faster convergence of an optimization algorithm.

Okay thanks. That sounds great. I looked at the package you linked me too and it's quite intriguing. I'll take a look Saturday when I get sick and tired of looking at my 1040.

Edited February 11, 2014 by Arrowstar

[diomedea]

Here's what you do. Use the optimizer as a "targeter" by minimizing the distance to Eve, using the main part of KSP TOT has the initial guess, as you've done. Do so first without any constraints and let it plow you right into the planet. Then, once you're headed into Eve's SoI, add constraints on radius of periapsis and inclination. Once you've got that licked, then add any maneuvers at Eve.

....

Oh, last tip: as of pre-release #2, you don't need the coast to the edge of Kerbin's SoI. Just make it a coast to Eve's periapsis and once the optimizer gets you in the SoI, you'll go there no problem.

Ok, thanks. I did another bunch of tests using your suggestions.

At first could not make the optimizer work, generally only receiving errors or nothing better than the initial guess. I won't annoy you with hours worth of tries. In the end, by trial and error, I found the following that made the optimizer provide what appears to be a valid solution (non identical, but close to the initial guess from KSPTOT):

- set the objective as you suggested, minimum distance from Eve in the optimizer; no constraints in the right panel;

- with the burn event, to be optimized, set the upper bound for DV to a suitable value: the optimizer opens with the bounds for DV set =0 and cancels out any speed change as a result, if those defaults are not tweaked;

- have another coast event, before the one set for Eve's periapsis that you suggested, and allow also the first coast event to be optimized (again, removing default bounds). The final coast (to Eve's periapsis) is not available for optimization (I must say, contrary to what I would expect), therefore arrival time can only be optimized because of the previous coast.

Ok, I know I am testing a non-finished product, and the amount of features it provides require some knowledge to use correctly.

Please consider how important it is to provide detailed instructions, as some potential users can't spend a lot of time trying it to see what works and what not.

[FanaticalFighter]

The new Mission Architect is pretty much like a GMAT for KSP xD. Awesome work, Arrowstar! I just wish you post a tutorial for the Mission Optimizer, because some things there are a bit confusing.

[Arrowstar]

Ok, thanks. I did another bunch of tests using your suggestions.

At first could not make the optimizer work, generally only receiving errors or nothing better than the initial guess. I won't annoy you with hours worth of tries.

Could I get these error messages from you? If I know what you're doing wrong, I can try to build in stops to these more common issues that prevent people from making the same mistake in the future.

Ok, I know I am testing a non-finished product, and the amount of features it provides require some knowledge to use correctly.

Please consider how important it is to provide detailed instructions, as some potential users can't spend a lot of time trying it to see what works and what not.

Certainly! I'll include a tutorial with the 0.12 release. Perhaps I'll model the Kerbin->Ike transfer I included, plus some other things.

The new Mission Architect is pretty much like a GMAT for KSP xD. Awesome work, Arrowstar! I just wish you post a tutorial for the Mission Optimizer, because some things there are a bit confusing.

Thanks! Yes, as I said above, I'll write up a tutorial and include it with the final 0.12 release.

Right, so last night I finished up the state log and modified the tab order of all the GUIs so they made sense. I also got a start on vectorizing the "minimize distance to target" objective function. The reason this is important is because this function includes a loop over the state log that the application records, and that's what makes the whole optimization slow right now. If I can get this vectorized, then I expect the already fast optimization will go much, much faster, and all will be happy.

Keep letting me know about suggestions and whatnot, everyone. I want to make Mission Architect the best I can, and that's not possible without great user feedback.

[PlonioFludrasco]

Guys I'm having problems with the rendezvous tool.

When I upload maneuvers, the result is a strange transfer orbit with encounter markers indicating something like "closest approach 900 km" .

I was trying that to rendevous from 100km height orbit to my station on a 200km height orbit, and an encounter at 900km is not that good....

Is there anybody that can explain me how to use the Rv tool properly?

[diomedea]

Could I get these error messages from you? If I know what you're doing wrong, I can try to build in stops to these more common issues that prevent people from making the same mistake in the future.

Let me say, there are various things that can possibily go wrong (and I am sure I have not even found them all); but not always that easy to tell what is the problem.

Sometimes the optimizer "hangs" after the first iteration. I have this happen consistently if I forget to give a final coast maneuver in the plan that makes sense; e.g., if I set as objective for the optimizer "minimize distance from Eve", I must have a coast after the maneuvers to be optimized, that goes to the periapsis of Eve. I did that mistake a lot of times, as I could not understand what was happening. I am sure other conditions need to be set or the optimizer hangs, but I don't have a firm streak of other cases.

Other times, it is the applet drawing trajectories that keeps telling "working" forever and never updating.

There were, at times, windows telling something like an "index not found" or what seems like a function not having the correct parameters (something like fmincon ?). I will try to summon those again.

I am still trying to enter the SoI of a children (e.g. Eve) after a transfer around the parent body (Sun). Even if the solution found by the optimizer is similar to what I expect, there is not a SoI transition event, nor anything related with the children displayed on the map.

If I try to set a plan to coast to next SoI, I will get the warning: Cannot coast to SoI transition (no SoI transition found).

Anyway, the above is rather sparse information, and I believe it should be possible to provide something better. Here is the ksptotlog.txt file, I see it includes error reports, though not very much about what was going on at that time. If you can provide me with the proper instructions to get more complete reports, I will do.

[Arrowstar]

Guys I'm having problems with the rendezvous tool.

When I upload maneuvers, the result is a strange transfer orbit with encounter markers indicating something like "closest approach 900 km" .

I was trying that to rendevous from 100km height orbit to my station on a 200km height orbit, and an encounter at 900km is not that good....

Is there anybody that can explain me how to use the Rv tool properly?

Can you take a screenshot of the GUI and post it here? Which version are you using? The released v0.11 or the 0.12 pre-release?

Let me say, there are various things that can possibily go wrong (and I am sure I have not even found them all); but not always that easy to tell what is the problem.

Sometimes the optimizer "hangs" after the first iteration. I have this happen consistently if I forget to give a final coast maneuver in the plan that makes sense; e.g., if I set as objective for the optimizer "minimize distance from Eve", I must have a coast after the maneuvers to be optimized, that goes to the periapsis of Eve. I did that mistake a lot of times, as I could not understand what was happening. I am sure other conditions need to be set or the optimizer hangs, but I don't have a firm streak of other cases.

Other times, it is the applet drawing trajectories that keeps telling "working" forever and never updating.

There were, at times, windows telling something like an "index not found" or what seems like a function not having the correct parameters (something like fmincon ?). I will try to summon those again.

I am still trying to enter the SoI of a children (e.g. Eve) after a transfer around the parent body (Sun). Even if the solution found by the optimizer is similar to what I expect, there is not a SoI transition event, nor anything related with the children displayed on the map.

If I try to set a plan to coast to next SoI, I will get the warning: Cannot coast to SoI transition (no SoI transition found).

Anyway, the above is rather sparse information, and I believe it should be possible to provide something better. Here is the ksptotlog.txt file, I see it includes error reports, though not very much about what was going on at that time. If you can provide me with the proper instructions to get more complete reports, I will do.

Bet way to help me out is the give me a save file (*.mat) that shows the error. Take a picture of the optimizer input GUI is if you were using that. Once I have these, I'll take a look and troubleshoot.

[PlonioFludrasco]

I don't know the version, is written somewhere?

EDIT: RV tool works, it was only me doing everything wrong

Could you explain me how to use it plz?

Edited February 14, 2014 by PlonioFludrasco

[Arrowstar]

Oh cool. What were you doing? Maybe I can fix or mitigate the issue.

[PlonioFludrasco]

I was trying to approach a station on a higher Kerbin orbit.

But I think the issue it's that I'm noob with that tool:D

The only thing I think is not caused by my noobness, is that sometimes it plots transfer orbits that pass through the atmosphere or the planet itself.

Is there any option I haven't noticed (p.e. some periapsis restriction) or I just have to compute another transfer with a later epoch (it seems it works)?

EDIT Oh I was forgetting about... I've noticed that the maneuvre assistant doesn't accept negative values for delta-v. It's ok? Does it have any consequence(I mean on my kerbals) if I delete the "-" and proceed anyway?

Edited February 14, 2014 by PlonioFludrasco

[chicknblender]

I just discovered KSP TOT earlier this evening (referred from a user on Reddit). I had been trying (and failing) for many hours over the past week to make good use of a gravity assist. (I got it conceptually but couldn't really do anything useful.) Within 2 hours of download, I got to Moho for ÃŽâ€v of only 3,030 m/s. AWESOME tool! I had to create an account here just to say thanks! I guess now I've got a new site to get my KSP fix.

[Arrowstar]

I just discovered KSP TOT earlier this evening (referred from a user on Reddit). I had been trying (and failing) for many hours over the past week to make good use of a gravity assist. (I got it conceptually but couldn't really do anything useful.) Within 2 hours of download, I got to Moho for ÃŽâ€v of only 3,030 m/s. AWESOME tool! I had to create an account here just to say thanks! I guess now I've got a new site to get my KSP fix.

Hi chicknblender! Thanks for using KSP TOT! I'm glad to hear you got it working for you and your missions have been successful. If you have any questions, please post here and me know!

To everyone else: sorry for the absence over the past few weeks. I've needed a bit of a creative break and work has been a bit overbearing. I will resume work on the next version and Mission Architect hopefully next week. Hang in there.

[Drew Kerman]

I didn't see anything about FAR in the OP - is this tool meant for only the stock version of KSP?

[chicknblender]

After a lot more experimentation, I am starting to note that the insertion ÃŽâ€v at Moho (after a Kerbin-to-Eve TOT-calculated flyby) varies a good bit. I've gotten it as low as 1400 m/s and as high as 2500 m/s. Is insertion ÃŽâ€v factored into the flyby sequencer's calculations? Am I just not lining things up as perfect as they have to be?

Another question: I haven't really used TOT for direct transfers since I'm mostly interested in gravity assists, but is there any consensus or opinions about how this tool compares (in terms of best-solution accuracy, not other features) to Alex Moon's browser-based calculator? Not trying to start a fight, just curious.

Edited March 2, 2014 by chicknblender

[chicknblender]

I didn't see anything about FAR in the OP - is this tool meant for only the stock version of KSP?

I'm still a noob when it comes to this tool specifically, but as far as I can tell it is only calculating orbital maneuvers (outside of atmosphere) so FAR should have no effect on it.

[Camacha]

is there any consensus or opinions about how this tool compares (in terms of best-solution accuracy, not other features) to Alex Moon's browser-based calculator? Not trying to start a fight, just curious.

Asking about efficiency seems only natural when it comes to rocket science