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

[draeath]

What does that have to do with it? I thought your orbit was measured from the center of the elipse, not the surface of the body?

If that's not the case this would explain things, eh?

[Spanier]

This program is awesome, and you should feel awesome for writing it!

*Especially* that you allow reading state-files instead of requiring us to figure out and manually input all the parameters.

Though, what I don't understand is how a 100km orbit (circular) has an SMA of 400. Shouldn't it be 200? If I enter 200 the tool behaves as if I was inside Kerbin instead of around it. Doubling that to 400 draws the orbit as I would expect to see in-game while at 100km apo/peri.

SMA means semi-major axis, and if you are in a circular orbit this is equivalent to your orbits radius, and this equal to the radius of the orbited planet + your distance to the planet's surface. So you get a 700km SMA for a 100km Kerbin orbit

[Frederf]

It's been a great read so far and very impressive. My contribution is outmatched in the realm of numerical analysis but I think I have something of value.

My thoughts turn to more practical matters like error analysis. Mission planning to the proverbial deltaV penny is foolish. I would be interested in sensitivities for +- time or speed for transfers in terms of corrections or even end game non-optimal captures. Knowing that +-10 seconds results in 200 dV would be invaluable for planning.

Also often fuel minimization isn't the priority. Sometimes one has X dV and is interested in minimum time. This was touched on earlier.

Lastly check values would be nice to verify that the maneuver is going well and what errors and how serious they are can be realized.

One thought about timing parking orbit burns. Perhaps a 2-burn method is practical to synchronize Pe with impulse point. For example if one executes 20.524652 orbits between now and burn perhaps TOT could suggest the minimal parking orbit alteration to achieve exactly 20 or 21 orbits. Thus later when one wants to escape it just happens to be at the best point in the orbit.

[Hour Hero Yes]

I am also unable to load my SFS file into the burn calculator. What sort of info can I give to help?

[mcirish3]

I am having an odd problem with this tool. It will not give back a good pork chop plot or the correct time to leave if I use any dated other than year 1 day 1 00:00.00 as my start time. I want it to calculate a moho to eve transfer but it won't do it, any help possible with this?

[The Lone Wolfling]

I am having an odd problem with this tool. It will not give back a good pork chop plot or the correct time to leave if I use any dated other than year 1 day 1 00:00.00 as my start time. I want it to calculate a moho to eve transfer but it won't do it, any help possible with this?

Did you change the minimum arrival time?

[mcirish3]

Did you change the minimum arrival time?

Yes of course. I should not have said it won't plot the trajectory but the date it gave for departure is before the date I put in.

[Arrowstar]

Hi everyone! Sorry I've been gone for so long. I thought I'd be able to get back last week, but it just didn't work out. Unfortunately, come Wednesday, the situation is going to get worse again. I think that I'll put out 0.9 tonight in whatever state I've got it and you guys can tell me what you think. I'll work on it as time allows.

I'll comment on some recent posts.

I am also unable to load my SFS file into the burn calculator. What sort of info can I give to help?

Please provide the SFS file (link to it here).

I am having an odd problem with this tool. It will not give back a good pork chop plot or the correct time to leave if I use any dated other than year 1 day 1 00:00.00 as my start time. I want it to calculate a moho to eve transfer but it won't do it, any help possible with this?

Yes of course. I should not have said it won't plot the trajectory but the date it gave for departure is before the date I put in.

Can I see a screenshot of what you entered? (Please include the main window and any other windows you have open.) I imagine it's something straight-forward.

[mcirish3]

Here are two screenshots. First I ran a trip from Kerbin to Moho, to get a time. for when I would get to moho. I then used that time to get a window from Moho to Eve, wanting to leave after my arrival time but it always gives out a date before I actually would arrive at moho. see below\|/

[Arrowstar]

Try bumping up your earliest Eve arrival time by 20-40 days (or slightly more) and tell me what happens.

[mcirish3]

I actually have had it do a fly by calculation for eve as the fly by and that worked fine when I used that time. Which by the way is what I really plan on doing. Not sure if that helps I got sidelined since this question lead me to other bigger questions about the KSP universe. I just figured out the total period of the KSP Kerbol system which by the way is 283855345821049673891877587109375021644538854676353552439197770387057442399150288400 s or 10^76 years ( i did not take roation of the planets into account)

[Arrowstar]

Hi everyone,

As promised, here's a 0.9 pre-release. It's a bit rushed, as life is crowding cool stuff like this out at the moment. Could I get some feedback?

Big new features are:

SFS issues should hopefully be resolved once and for all;

You can now input a mean anomaly and epoch (or get it from an SFS file) and the code will calculate a new departure time such that your spacecraft is at the right place at the right time.

This is a pre-release. As with the 0.7 pre-release, I'm just providing the executable. If this makes you uncomfortable, please wait for the official release.

Get it here.

Comments, questions, concerns, please let me know!

EDIT: I know the status box still says 0.8... I'll fix later lol.

[Arrowstar]

I actually have had it do a fly by calculation for eve as the fly by and that worked fine when I used that time. Which by the way is what I really plan on doing. Not sure if that helps I got sidelined since this question lead me to other bigger questions about the KSP universe. I just figured out the total period of the KSP Kerbol system which by the way is 283855345821049673891877587109375021644538854676353552439197770387057442399150288400 s or 10^76 years ( i did not take roation of the planets into account)

I'll admit, I'm still a bit confused as to what you're after. Could you please clarify your question?

[mcirish3]

Well to be honest I am confused as to why I got the odd result shown in the pictures above. Clearly there is a weakness in the program that caused the problem. Now that I have figured out a workaround as I stated above it really is not a big deal any more. but it definitely could be a problem if it presented itself in other situations, say for example a hyperbolic trajectory.

Edited August 5, 2013 by mcirish3

[Arrowstar]

I'll be completely honest, I still don't see the problem. So far as I can tell, the program is behaving normally. Please, in very clear words, describe what you see the problem as.

(I'm going to go out on a limb here and suggest that there's a misunderstanding of how to use KSP TOT at the core of this discussion and not some technical issue...)

[Spanier]

Why does the flyby calculator never return direct encounters with the flyby body, so the transfer orbit cycles around the sun more than once?

[Arrowstar]

Typically at least one rev around the sun is required for proper orbit phasing (meaning timing of the encounters). That is the price of flybys: longer transfer orbit duration for smaller delta-v requirements.

[Spanier]

WTF just happened?

[Peewee]

No idea, those inputs produced this result for me:

[themooseontheleft]

I created a KSP forum account just to tell you this. Your applet is beautiful. I just downloaded it and ran some tests simulations. I absolutely love it.

If I could suggest any feature I'd like to see next (and it may already exist without my having discovered it yet) it would be the ability to input a flyby trajectory, rather than an orbit, so that simulations of flyby scenarios can be linked (i.e. a calculated flyby trajectory can be input into another flyby simulation). Thanks for the app. I'll definitely be using it.

[Arrowstar]

Spanier/Peewee: Thanks for the information! The numerical solver used doesn't always converge to a realistic solution in some cases. Occasionally the solver will find a really cheap solution that also happens to be impossible. I've got constraints in there to prevent most of this, but it's not always possible to get it all. Just rerun the simulation and see if that fixes the issue.

Themooseontheleft: Thanks! It is indeed a nice little tool and I enjoy using it myself. Glad to hear you're getting some mileage out of it. To answer your question: you can indeed do what you're asking, it's just not advertised. After you compute a flyby, go ahead and encounter the planet you're attempting to fly by in KSP. Immediately at SOI change, create a new porkchop plot with the departure body as the body you're flying by and the arrival body as the final destination of the flyby sequence. After this, go to the Compute Departure button on the main GUI. Enter your periapse time in the departure time field and the final destination body arrival time from the flyby plan into the arrival time field. Then enter your hyperbolic orbit elements into the orbit panel on the right and tap Compute. It should do the math for you. As a friendly hint, you should try very hard to at least get the inclination and RAAN roughly what they are in the flyby plan or the solver will have a hard time converging.

Let me know if you have any questions! Feel free to post pictures of oddities or just nice trajectories you've found.

[Spanier]

I had this "bug" recently in 0.9 prerelease, can I fix it myself:

[Specialist290]

Getting the same bug as Spanier on my install as well on my first try of the Flyby Calculator.

That said, overall this seems to be a rather well-put-together program.

[Arrowstar]

Ooo, I bet that's because I removed the Parallel Computing Toolbox from the install to decrease file size. Ugh. Does that occur in 0.8?

EDIT: Just as a heads up, guys, the reason development has slowed to the extent that it has is because I've been pulling 60 hour weeks at work the last two weeks. That's scheduled to end after next week, so after life calms down I'll get back on the development wagon. Besides fixing this bug, I'll also go ahead try to implement a feature I've wanted to do for a while: the maneuver execution assistant. Give it your initial orbit, delta-v vector, and some spacecraft mass properties and it'll find the delta-v centered time to start your burn. This will be most applicable to long burns on heavy vehicles, where the "split the time difference" operation actually biases the burn (and thus the final orbit) to what happens after the maneuver node.

More details on this later...

Edited August 15, 2013 by Arrowstar

[BigMorgan]

Thank you for saving us math-impaired folks from ourselves. This is the best tool yet made for KSP. If people consider MechJeb "cheating" then your calculator is the KSP equivalent of the mafia bribing the referee of a football game so their bets pay off. Thank you, again!