[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[chicknblender]

OK in trying to do the research to answer my own question, I have noted that the Flyby Maneuver Sequencer will come up with different maneuvers when given identical starting parameters. I am assuming there is some sort of randomness build into the algorithm that is then optimized?

I am still trying to find an answer to finding flyby maneuvers that result in minimum expended ÃŽâ€v, including insertion ÃŽâ€v. So far I have found that variation in my flybys (leaving the same date from Kerbin and then "getting sloppy" at some point on the way to Eve) can change my insertion ÃŽâ€v at Moho by at least 500 m/s. (Yes this is with similar Moho periapses.) Additional advice would be appreciated.

Edited March 4, 2014 by chicknblender

[Camacha]

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.

Like I always say to the other modders: be sure to have fun and not to burn yourself out. This whole thing should be enjoyable and not feel like a chore.

[tavert]

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.

From page 1, about 9 months ago:

So if you're going for a higher-featured version of Alexmun's Javascript porkchop plotter, you may have noticed he has a 2-burn transfer mode using an ecliptic-projection initial ejection burn and a mid-course plane change, that actually ends up noticeably more efficient in some cases (take a look at the first Dres transfer for example).

Don't think Arrowstar has implemented the 2-burn transfers yet, but please correct me if I'm wrong.

[Aghanim]

Oh my god. Finally my suggestion is implemented. How do your ingame plugin and this program communicate?

[Arrowstar]

Hi everyone, sorry for the delay in providing responses. I'll try to get to everyone's comments and questions here.

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

KSP TOT does not consider atmospheric interactions in any of its calculations. Thus, you'll get the same experience with or without FAR installed.

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?

Insertion delta-v is factored in. However, the flyby code uses a particle swarm optimizer and there is a degree of randomness involved. It is normal and expected to get different results on different runs, and you may need to use the tool a few times to find something acceptable.

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.

It should be effectively identical. But KSP TOT does a lot more and has a lot more features than Alex's code. Don't get me wrong, I actually like what he's put together, but KSP TOT is for people who want to do lots of trajectory analysis work.

OK in trying to do the research to answer my own question, I have noted that the Flyby Maneuver Sequencer will come up with different maneuvers when given identical starting parameters. I am assuming there is some sort of randomness build into the algorithm that is then optimized?

I am still trying to find an answer to finding flyby maneuvers that result in minimum expended ÃŽâ€v, including insertion ÃŽâ€v. So far I have found that variation in my flybys (leaving the same date from Kerbin and then "getting sloppy" at some point on the way to Eve) can change my insertion ÃŽâ€v at Moho by at least 500 m/s. (Yes this is with similar Moho periapses.) Additional advice would be appreciated.

See above, there is a fair bit of randomness in the generation of the solution. The optimal flyby problem is hard to solve, and I elected to do so by throwing CPU at the problem. Of course, the code could probably use an update and some optimization itself, but it seems to work alright for now.

Like I always say to the other modders: be sure to have fun and not to burn yourself out. This whole thing should be enjoyable and not feel like a chore.

Thanks!

Don't think Arrowstar has implemented the 2-burn transfers yet, but please correct me if I'm wrong.

Correct, I have not yet. I'm not particularly familiar with this family of transfer, though. Could you (or someone else) describe what you mean?

Oh my god. Finally my suggestion is implemented. How do your ingame plugin and this program communicate?

The connection is made via TCP/IP.

[Camacha]

I totally understand you have probably lots of other more important things to do, but I am fairly curious about the math involved in this. I am getting deeper into control logic and that has been starting to cross over into orbital mechanics. I get a kick out of not only finding a good solution, but working on something until I have the best solution I can provide (which is not necessarily the same as the best ). I have managed to build a little solver that calculates the needed burn time to end up exactly at a certain height, but how one would tackle something like this is beyond me.

Do you have any good reading material or maybe things written yourself?

Edited March 9, 2014 by Camacha

[Arrowstar]

Depends on what you mean by good reading material. If you're well versed in orbital mechanics, I would suggest Fundamentals of Astrodyanmics and Applications by Vallado. This is the single greatest orbits text you can find anywhere, hands down. I own a copy and I use it extensively when writing code for KSP TOT. If you're not that big into the orbital math yet, I would recommend something like this website. Or just Google "basic orbital mechanics."

Now, do you have particular questions? I can't give a run down on all the math in KSP TOT, but I'd be happy to share how I did particular things. Always fun to talk about orbits with people who like to learn.

[Camacha]

I would recommend something like this website.

Yes, that is a wonderful website - concise yet complete. I am by no means an expert when dealing with orbits, but the internet is a treasure trove when it comes to these things.

I understand my question was a little generic. I think my main interests are the practicalities of turning the physics into a program - how to get those formulas together into something that is actually useful. In reality I think that means I will have to experiment a little more and ask any specific questions I come up with.

In an ideal world where I had all the time I would love to write a program like yours. It can not hurt to at least start working towards that goal.

[chicknblender]

Arrowstar, thanks again for this awesome tool. I have really been putting it to use. Here is an album from my ultralight mission to Moho: http://imgur.com/a/tjuan

Using the flyby sequencer got my delta V down to 4.4 km/s total on the transfers, about 1.6 km/s less than direct transfers. Really great program, and I'll be exploring the other features in the future.

Now for my question: If insertion delta V is already being considered, would it be possible to get this information displayed on the results screen?

Edited March 12, 2014 by chicknblender

[Sirius]

Hey there,

I can't seem to get the MCC Real Time System to work at all, just says Could not connect... I've disabled windows firewall and have run as administrator. I'm not sure if KSPTOT connect is working at all despite being installed within the GameData folder. I'm also unable to pull any kind of orbit info from KSP, pulling the UT is just fine though. I've tried with both the download link on first page and the pre-release version of v12.

I'm currently running windows 8.1 x64 if that makes a difference.

Lastly, I've done a few maneuvers with the program outlined by the tutorial. A return trip from moho has a 1.6M km separation, is this normal? I launched within 25 minutes of the window given by the program, set up the time before periapsis and burn info, and had about a 6 minute burn time.

Edited March 12, 2014 by Sirius

[Arrowstar]

Now for my question: If insertion delta V is already being considered, would it be possible to get this information displayed on the results screen?

So I believe the DV being considered is just the Lambert-based delta-v. This isn't actually what you'd need to stop at the destination planet. Computing that is much harder because it involves knowing what your arrival orbit is and what your target orbit is. I've thought about this problem for a while, and the short answer is that it's probably not particularly valuable. In the mean time, I probably won't be displaying this information directly. However, if you know your inbound orbit and your target orbit, you can use the two-burn orbit change code to perform the required math for you and get the result you seek. So no, it probably won't be on the results screens, but there are other ways (the way I just listed) to get what you're after.

Does that help?

Hey there,

I can't seem to get the MCC Real Time System to work at all, just says Could not connect... I've disabled windows firewall and have run as administrator. I'm not sure if KSPTOT connect is working at all despite being installed within the GameData folder. I'm also unable to pull any kind of orbit info from KSP, pulling the UT is just fine though. I've tried with both the download link on first page and the pre-release version of v12.

I'm currently running windows 8.1 x64 if that makes a difference.

Lastly, I've done a few maneuvers with the program outlined by the tutorial. A return trip from moho has a 1.6M km separation, is this normal? I launched within 25 minutes of the window given by the program, set up the time before periapsis and burn info, and had about a 6 minute burn time.

So UT retrieval works but not anything else? That is very weird. When you start KSP in the flight scene (that is, go to launch a rocket or whatever), open up the debug log and see what's in there. Should be something about KSPTOT Connect starting a server. Can you look for that? Maybe take a screenshot and post it here?

[Sirius]

Yeah there is nothing about KSPTOT starting a server, yet under Database > Assemblies in the alt-f12 box shows KSPTOTConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

That is the only reference I see to KSPTOT. I'm currently running Better than starting Manned, KWrocketry, mechjeb, preciseNode, deadly reentry, enhancedNavBall, kethane, protractor, scansat, and a few other minor plugins.

[Arrowstar]

Yeah there is nothing about KSPTOT starting a server, yet under Database > Assemblies in the alt-f12 box shows KSPTOTConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

That is the only reference I see to KSPTOT. I'm currently running Better than starting Manned, KWrocketry, mechjeb, preciseNode, deadly reentry, enhancedNavBall, kethane, protractor, scansat, and a few other minor plugins.

Okay. Can you try on a clean no mods KSP install for me and see if you get something?

[Sirius]

Apparently it's something wrong with my save. The save was created before installing KSPTOT. A new game runs KSPTOT connect just fine.

[Arrowstar]

Got it. So are you all set or still experiencing an issue?

[Sirius]

Yeah I'm set, thanks. Unfortunately it was a very advanced career save. Oh well.

I do have a question on how the calculations can compute time after/before periapsis but not the precise UT to start the burn. Also the moho burn I computed was way off, does the program ever compute multiple burns or does it just do ballistic trajectories?

[Arrowstar]

Yeah I'm set, thanks. Unfortunately it was a very advanced career save. Oh well.

I do have a question on how the calculations can compute time after/before periapsis but not the precise UT to start the burn. Also the moho burn I computed was way off, does the program ever compute multiple burns or does it just do ballistic trajectories?

Ah. That would be because KSPTOT doesn't actually know what time it is. However, it does know the location of the burn and the mean motion of the orbit, and from there it can figure out the time relative to periapsis.

I guess I don't understand your last question. In what way was the Moho burn off? In the program or in KSP? If it was in KSP, this was probably just the infinitesimal local gravity field assumption screwing up the burn a bit. You shouldn't be that far off, though. Try moving the maneuver node around with a maneuver node editor. I think I have a tutorial linked in the OP that explains how to do that a bit.

[Arrowstar]

Hi all,

Just wanted to let you know that I've restarted work on KSP TOT Mission Architect. My goal is now to get a finalized v0.12 out this weekend. Really, everything is mostly coming together, I just need to get the details (minor bugs/annoyances, tooltips, some documentation) taken care of.

If you've used MA in the past and have comments, now's the time to let me know about them. I'm not sure how much time I'll devote to KSP TOT in the immediate future after the 0.12 release. I will keep supporting it and bug fixing of course, but it's a pretty time consuming endeavor and I occasionally need to go on breaks for a few weeks/months to recharge.

[diomedea]

Let me ask again about documentation. But, I can't provide details on how to improve that, as it is now almost non-existing (one single example).

I tried many times to use KSPTOT MA, and am sure I am making stupid mistakes. Why I can't enter the SoI of a minor body after a transfer with the objective set for it? What if I want to set a transfer for the minimum possible approach speed to a body? How, really, constraints should be set across different stages?

The only way for me to learn is to find a step-by-step guide for such cases. Or, at the very least, some good examples. I believe it won't cost you too much time to include some more examples with version 0.12, covering the more common use cases (and, why not, even some complex case to show the power of your tool).

[Specialist290]

Glad to hear you're still working on this, Arrowstar. I'll definitely be looking forward to taking the new version for a spin.

[Starstrider42]

Yay, finally a tool that lets you plan gravity assists!

One question/complaint, though: in the flyby planner, is there a way to abort the calculation? Some of the problems I've given it got stuck at the "Finding feasible initial positions" window, presumably because the transfer I wanted wasn't actually possible. Unfortunately, that meant I had to kill the entire program before I could try again.

[Inconvenience]

This is a very nice and helpful plugin, thank you.

Quick question: is there some way that I could manually input the new planets in the Planet Factory mod? I could likely find the orbital characteristics of all the planets, but is there somewhere to put this and some way to format it?

[borisperrons]

Well, what the hell, now I feel like the proper NASA.

Just a question, it's normal that calculations take up ages? I mean, the best part of an hour.

[usulrasolas]

Okay, playing with this a bit... but for it to be superdupermegagigantanormous (patent pending). It should support rss (drool, or with the planetfactory tweaks for rss).

I know, I know, realism and kerbal seem sorta counter intuitive, but a tool like this could help an amazing amount with the hungry gravity wells eating up my dV and the mechjeb and standard transfer planning tools not really working very well for rss. Really I just want to get to duna in rss with planetfactory without a 600-900 day lapse inbetween goes, and I lack the patience to try and calc a flyby or slow transfer by hand.

Okay, so I guess it does this? but I am still trying to figure out how to get the plugin to digest the solar system... or whatever it's called.

Edited March 26, 2014 by usulrasolas
I'm dumb sometimes

[usulrasolas]

Ah, nvm... I guess I have to make my own bodies file? is this correct?