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

[diomedea]

...

So anyway, in short, I may just tackle this to see if I can't solve the problem of doing multi-body gravity assists quickly using a vectorized Lambert solver.

...

Hats off to you! While I'm just an amateur, I read something about Lambert solvers, and never came across any in a vectorized form.

Hope this new enterprise isn't just because of my insistence, but because you find true interest in it .

[Arrowstar]

Hats off to you! While I'm just an amateur, I read something about Lambert solvers, and never came across any in a vectorized form.

Hope this new enterprise isn't just because of my insistence, but because you find true interest in it .

Nah. I mean, you're not the first person to ask, so I know people would like the functionality. Up until recently, though, I hadn't tried my hand at complex vectorized functions, though, which is what will be necessary to maybe pull this off (might not work still, but we'll see). And yes, I do find the thought of a vectorized Lambert solver very interesting.

I should explain what I mean by "vectorized" since it is a MATLAB term. In MATLAB, for an array of arguments, there are two ways of operating on said arguments. The first is to write a loop and operate on each argument in serial. Second is to write code that uses vector math (what you learned in high school/secondary school mathematics) to do the same operations "in parallel." In MATLAB this matters, because as its name suggestions, MATLAB is very good at vector/matrix operations. It's looping, on the other hand, is fine for "small" numbers of iterations but tends to be slower at "larger" number of iterations. To do the optimization of multi-body gravity assists, I will have to call a Lambert solver many many times. In order to do that efficiently, I need to use MATLAB's native, fast vector operations to do it all at once. Looping would be too slow by far.

Anyway, I'll let you know how it goes. Go play with v0.12.3.

[PlonioFludrasco]

Wow, Mission Architect is amazing!

But how to launch into the planned initial orbit?

[Arrowstar]

Wow, Mission Architect is amazing!

But how to launch into the planned initial orbit?

Thanks!

Well, as Dr. von Kerman would say, "that is not my department." There used to be an optimal launch trajectory tool somewhere on this forum, but I can't remember what it's called. Or you can just guess the approximate right time to launch, wing it, and update your mission plan's initial state from KSP after you separate. Then just reoptimize the mission plan.

[Wadusher0]

Wow, Mission Architect is amazing!

But how to launch into the planned initial orbit?

MechJeb and I would assume Ascent Komputron would help you in this regard.

http://ascentkomputron.blogspot.ca/

[Arrowstar]

MechJeb and I would assume Ascent Komputron would help you in this regard.

http://ascentkomputron.blogspot.ca/

Thank you for the link!

[Arrowstar]

Alright, diomedea, I have some good news. I finished up the first draft of the multi-body flyby optimization objective function today. The good news is that, after doing some performance testing, the code is approximately 100x faster than the same code being used in the current flyby maneuver sequencer. Believe it or not, this was more or less my feasibility target for a multi-body flyby code. In short, I nailed it.

Some quick numbers:

Evaluating the objective function 1000 times using the new code: 0.115 seconds.

Evaluating the objective function 1000 times using the old code: ~12 seconds.

This should be fast enough to handle multiple flyby navigation solutions... hopefully. In any event, I think your little project is a go.

Tomorrow I will try to get a test case together using the new objective function. Completing this task will effectively wrap up all the loose ends I'll be leaving tonight. I'll let you (and everyone else!) know how it goes.

Edited May 27, 2014 by Arrowstar

[Galane]

That's an amazing speed improvement! Over 104 times faster. (12/0.115) Care to share any insights into what you changed to make such an improvement?

"objection function"? Sounds like what a Kerbal does when he doesn't want to be sent on a multi-body flyby mission, optimized or not.

[Arrowstar]

That's an amazing speed improvement! Over 104 times faster. (12/0.115) Care to share any insights into what you changed to make such an improvement?

Sure! It's very straight-forward sounding, but it takes a bit of effort to implement. Namely, I vectorized every function call within the objective function. This means that I have (almost) no loops within the objective function. It also means that the objective function only gets called once regardless of how many "particles" or "individuals" I have within the population of solutions the global optimizer is using at the moment. Every "individual" in the "population" gets passed into the objective function all at once and gets operated on all at once. Compare to the way it's currently being done in Flyby Maneuver Sequencer, in which every individual gets treated separately, and the objective function is called one time per individual per iteration, instead of just once per iteration.

Eliminating the loops is a matter of using MATLAB's inherently fast matrix/vector math engine to do mathematical operations in "parallel" instead of looping over the operation and doing them in serial. (Parallel in quotes because I suspect that it's still being done in serial underneath it all, but the code that does the matrix math is just so bloody fast that you don't notice.) Anyways, since loops in MATLAB are somewhat slow (though they have gotten faster!) and definitely slower compared to the native matrix math libraries MATLAB uses, by using vectors/matrices, I get huge improvements in speed.

Pretty cool, huh?

"objection function"? Sounds like what a Kerbal does when he doesn't want to be sent on a multi-body flyby mission, optimized or not.

Whoops.

[diomedea]

... I finished up the first draft of the multi-body flyby optimization objective function today. The good news is that, after doing some performance testing, the code is approximately 100x faster than the same code being used in the current flyby maneuver sequencer.

...

Tomorrow I will try to get a test case together using the new objective function. Completing this task will effectively wrap up all the loose ends I'll be leaving tonight. I'll let you (and everyone else!) know how it goes.

Excellent news indeed . This really opens the possibility of a viable use for a multibody flyby. Congrats for that achievement.

And, in case you need an independent tester for your test case(s), count me on!

[Arrowstar]

Sounds good, I will take you up on that. Since the forums are going down today for 48 hours, I will let you know how things are after it comes back online. I may even have a prototype GUI ready to go with a functioning back end by then... we'll see!

[Arrowstar]

Hi everyone!

I have some initial results of my efforts to put together a code that can find optimal multiple flyby trajectories. This is still very work-in-progress and some features are missing or only partially completed. The main functionality is in, though. I'll let some pictures do the talking. Please let me know what you think! I'm very interested in your feedback, as well.

Javascript is disabled. View full album

[Drew Kerman]

interesting. I was very intrigued by the fly-by plotter that popped up a few days ago - would be nice to have this in the mission planner for sure

[teal'c]

Just started to use the tool and so far it's looking very interesting.

I do have one question for using the flyby planner though. Can you add the amount of delta-v you'd need to insert into the arrival body? This way I can see exactly how much delta-v I can save by doing a gravity assist versus not doing one.

I can't seem to find a calculator online to determine insertion delta-v, so it would be nice if the tool would present it to me.

(Also, looking forward to multiple flyby sequencer )

Edited May 30, 2014 by teal'c

[diomedea]

Arrowstar, that multi-flyby is wonderful, excellent work!

Just because you are asking for feedback even at this early stage, though some features are not in yet.

Believe a set of data shown with each flyby would be nice (like, periapsis distance and UT, inclination, and sure Delta-V required as suggested by teal'c). Not sure if RAAN and Argument of Periapsis would be of interest for flybyers. Could be nice to have a value showing the total amount of Delta-V change due to the flyby, and some may find useful if that DV change could be split into prograde, normal and radial components (perhaps in the reference frame of the orbit before the flyby ?).

[Arrowstar]

interesting. I was very intrigued by the fly-by plotter that popped up a few days ago - would be nice to have this in the mission planner for sure

Which flyby plotter was that? Can I get a link? Or do you mean this one?

Just started to use the tool and so far it's looking very interesting.

I do have one question for using the flyby planner though. Can you add the amount of delta-v you'd need to insert into the arrival body? This way I can see exactly how much delta-v I can save by doing a gravity assist versus not doing one.

I can't seem to find a calculator online to determine insertion delta-v' date=' so it would be nice if the tool would present it to me.

(Also, looking forward to multiple flyby sequencer )[/quote']

The best I can do is the arrival V-Infinity. This number isn't delta-v, but it turns out that it's either really really hard or impossible to get the arrival delta-v, even if you know the target orbit, without using something like Mission Architect to do the planning with finite SoIs. Trust me, I've tried. I'll see what I can do, though.

Arrowstar, that multi-flyby is wonderful, excellent work!

Just because you are asking for feedback even at this early stage, though some features are not in yet.

Believe a set of data shown with each flyby would be nice (like, periapsis distance and UT, inclination, and sure Delta-V required as suggested by teal'c). Not sure if RAAN and Argument of Periapsis would be of interest for flybyers. Could be nice to have a value showing the total amount of Delta-V change due to the flyby, and some may find useful if that DV change could be split into prograde, normal and radial components (perhaps in the reference frame of the orbit before the flyby ?).

Each flyby will include the following information in the panels to the right:

1) Central body-centric transfer orbits;

2) Inbound and outbound hyperbolic orbits;

3) Delta-v required by the spacecraft engines at perigee of each flyby, in Prograde-Normal-Radial components.

The code will also show the delta-v vector needed to depart from the first waypoint, and it will provide the desired hyperbolic output orbit from that first waypoint, too.

Basically, the output text will be identical to that provided by the current Flyby Maneuver Sequencer, but it'll just include more flybys.

Does that all sound comprehensive, or would you like some other quantities?

[Drew Kerman]

Which flyby plotter was that? Can I get a link? Or do you mean this one?

Flyby Finder for KSP

[Starstrider42]

The best I can do is the arrival V-Infinity. This number isn't delta-v, but it turns out that it's either really really hard or impossible to get the arrival delta-v, even if you know the target orbit, without using something like Mission Architect to do the planning with finite SoIs. Trust me, I've tried. I'll see what I can do, though.

Even this would be pretty handy; we can get a rough estimate from v_inf and the escape speed.

But really, since the two-body calculator (with porkchop plots, etc.) includes arrival v_inf, it's only natural that the flyby calculator should include it as well.

[diomedea]

Each flyby will include the following information in the panels to the right:

1) Central body-centric transfer orbits;

2) Inbound and outbound hyperbolic orbits;

3) Delta-v required by the spacecraft engines at perigee of each flyby, in Prograde-Normal-Radial components.

The code will also show the delta-v vector needed to depart from the first waypoint, and it will provide the desired hyperbolic output orbit from that first waypoint, too.

Basically, the output text will be identical to that provided by the current Flyby Maneuver Sequencer, but it'll just include more flybys.

Does that all sound comprehensive, or would you like some other quantities?

That seems good, experience with the tool may suggest if more could be useful.

The current Flyby sequencer provides almost all the info required, so keeping that format will be great.

The only additional info I am considering is that total Delta-V obtained in a Flyby. I am considering values that may tell how effective a flyby is (so to help in planning) and my guess is total DV would be a nice way to measure that. The Flyby sequencer provides data about the transfer orbits around Sun before and after the flyby, but not the speed components (I assume what is meaningful is the speed at SoI transition with the flyby body), the difference of those speeds is mainly due to gravitational effects and burn at flyby, though some change is also due to distance difference to the central body. The effectiveness of the flyby could be given by the amount due to only gravitational effects from the flyby body. Probably other values could be used (perhaps eccentricity difference of the transfer orbits around Sun) but have to crank out some numbers from that to make in a sound "efficiency" value.

[Arrowstar]

Even this would be pretty handy; we can get a rough estimate from v_inf and the escape speed.

But really, since the two-body calculator (with porkchop plots, etc.) includes arrival v_inf, it's only natural that the flyby calculator should include it as well.

I've included it.

That seems good, experience with the tool may suggest if more could be useful.

The current Flyby sequencer provides almost all the info required, so keeping that format will be great.

The only additional info I am considering is that total Delta-V obtained in a Flyby. I am considering values that may tell how effective a flyby is (so to help in planning) and my guess is total DV would be a nice way to measure that. The Flyby sequencer provides data about the transfer orbits around Sun before and after the flyby, but not the speed components (I assume what is meaningful is the speed at SoI transition with the flyby body), the difference of those speeds is mainly due to gravitational effects and burn at flyby, though some change is also due to distance difference to the central body. The effectiveness of the flyby could be given by the amount due to only gravitational effects from the flyby body. Probably other values could be used (perhaps eccentricity difference of the transfer orbits around Sun) but have to crank out some numbers from that to make in a sound "efficiency" value.

So it's an interesting idea, for sure. However, there is a slight problem in that the quantity you're referring to (body-only flyby delta-v) is never actually computed because the transfer orbits are computed from point to point and require powered flyby delta-v in most cases to actually make the trajectory. In short, I'm not sure I can actually compute this.

In light of that, I guess I would suggest using the required engine delta-v as the metric of choice, with less delta-v being better. If DV is 0, then the flyby is as effective as it needs to be. Any delta-v you need to add with engines is essentially subtracting from that "perfect" flyby efficiency.

Does that sound okay or are you thinking of something else?

---

In other news, I have a pre-release for you all to play with! Get it here. I've left the original Flyby Maneuver Sequencer in for comparison's sake. Please try out the Multi-Flyby Maneuver Sequencer (MFMS) and let me know what you think. (Tools -> Maneuver Planning -> Multi-Flyby Maneuver Sequencer)

Also, as you'll notice, the upcoming version number will be v1.0.0. KSP TOT has been around for close to two years now and it's, in general, quite stable now. Therefore, I'm happy to announce that the next release will be the first "stable" release, as opposed to the "beta" releases of the v0.x.y series that I have put out to date.

Please let me know what you think of (MFMS)! I'm particularly concerned with bugs you find or suggestions that would improve usability. Thanks!

[Hannu]

I tried this program. It seems to be very good, I succeeded to plan a return from inclined and eccentric initial orbit on Moho and burn calculation was very accurate (I had just adjusted time few seconds in Mechjeb's Maneuver node editor). But now I have strange problems. It does not always detect SOI changes. I tried to make a plan to go to Tylo by same way that was used to go to Laythe in tutorial. First I planned trip from Kerbin orbit to Jool periapsis. First I set initial orbit. Then coast to UT and after that a burn by using time and velocity values given by departure burn window. These had optimization and some limits. Finally was coast to Jool periapsis. I optimized by minimizing distance to Jool and after about two minutes program gave a solution, which seemed to be reasonable.

Then I made optimization limits tighter (+-500 s and +- 50 m/s) and changed target body to Tylo and tried again. It did not succeed. I thougt that it may be impossible to achieve Tylo flyby by TJI burn and put correction burn about 3E6 seconds before Jool SOI. Then something very strange happened. Even if I forced burn to be 0 m/s, it lost Jool's SOI on that orbit and detected it on much later (about 1E8 s, probably 2 orbits later). I understand some inaccuracy, but Jool's SOI is huge and before 0 m/s correction it was almost on collision course. I am sure that I do something wrong or program do not detect SOI. I have changed reference bodies correct in Mission Architect and Optimization Window. UT times are checked. Can you say where the problem can be? I have also tried many more or less desperate things (divided coasts to shorter parts etc.) but without success.

I have also one question. If I have some angle 350 degrees and I want to have optimization range +-100 degrees, how should I tell it to software? I can not have maximum over 360 degrees and it also do not accept lower values as maximum. It would be more practical also in some other situations, if I could input optimization limits compared to initial guess.

[diomedea]

...

In light of that, I guess I would suggest using the required engine delta-v as the metric of choice, with less delta-v being better. If DV is 0, then the flyby is as effective as it needs to be. Any delta-v you need to add with engines is essentially subtracting from that "perfect" flyby efficiency.

Does that sound okay or are you thinking of something else?

I was driven to the idea of a measure of flyby efficiency by considering the possible benefit of gravity assist instead of a direct transfer. Actually, if beneficial, the flyby will let me use less total engine DV than the sum of the burns for a direct transfer. And however, I was only thinking about one specific flyby instead of the whole trip. You brought me back to reality, yes required engine DV is what must be considered, but would be meaningless if not considered over the whole trip.

[diomedea]

---

In other news, I have a pre-release for you all to play with! Get it here. I've left the original Flyby Maneuver Sequencer in for comparison's sake. Please try out the Multi-Flyby Maneuver Sequencer (MFMS) and let me know what you think. (Tools -> Maneuver Planning -> Multi-Flyby Maneuver Sequencer)

...

Please let me know what you think of (MFMS)! I'm particularly concerned with bugs you find or suggestions that would improve usability. Thanks!

Jaw dropped . Can't believe the speed. Watching the window while that "genetic algorithm" works, with all the scores changing in parallel, and computing generations so fast one can't follow any single one but just watch the values moving...

Did a try with a very awkward multiple flyby, from Kerbin to Eeloo passing around Eve and Duna, and even if the alignment was awful, the algorithm found a viable solution within one minute . What more could I ask?

Now, I am not yet sure if I am living a dream after having seen that.

However, there is one aspect I would like to be investigated. To compare the relative speed I made the same flyby with both the algorithms: a "simple" Kerbin-Eve-Duna, same starting condition and initial parameters. The multi algorithm found a different solution, requiring much less DV. Here the screenshots of the two. The plot of the transfer orbits is very similar (though projected to a different angle), and the single flyby plot is more "feature complete" currrently, showing planets positions. But information in the windows to the right is not similar.

[Arrowstar]

I tried this program. It seems to be very good, I succeeded to plan a return from inclined and eccentric initial orbit on Moho and burn calculation was very accurate (I had just adjusted time few seconds in Mechjeb's Maneuver node editor). But now I have strange problems. It does not always detect SOI changes. I tried to make a plan to go to Tylo by same way that was used to go to Laythe in tutorial. First I planned trip from Kerbin orbit to Jool periapsis. First I set initial orbit. Then coast to UT and after that a burn by using time and velocity values given by departure burn window. These had optimization and some limits. Finally was coast to Jool periapsis. I optimized by minimizing distance to Jool and after about two minutes program gave a solution, which seemed to be reasonable.

Then I made optimization limits tighter (+-500 s and +- 50 m/s) and changed target body to Tylo and tried again. It did not succeed. I thougt that it may be impossible to achieve Tylo flyby by TJI burn and put correction burn about 3E6 seconds before Jool SOI. Then something very strange happened. Even if I forced burn to be 0 m/s, it lost Jool's SOI on that orbit and detected it on much later (about 1E8 s, probably 2 orbits later). I understand some inaccuracy, but Jool's SOI is huge and before 0 m/s correction it was almost on collision course. I am sure that I do something wrong or program do not detect SOI. I have changed reference bodies correct in Mission Architect and Optimization Window. UT times are checked. Can you say where the problem can be? I have also tried many more or less desperate things (divided coasts to shorter parts etc.) but without success.

Interesting. Which version of KSP TOT are you using? The latest stable version is v0.12.3. You can find out which version you have by looking in the output text fields of the main KSP TOT GUI that appears when you first start the application.

I made some pretty big improvements to the SoI detection code when I went to v0.12.3. If you're not running this version, then that might explain it.

Nevertheless, can I please get a copy of the mission plan file (.mat file) you are using? Be sure it's the one that most immediately displays the problem. Just put a link to the file here in this thread. I also need you to describe, in steps, how to go from opening up that .mat file to getting the problem to show itself. Once I have all that, I'll start investigating. If you get it to me today, I may even be able to get a fix out this evening, assuming one is needed.

I have also one question. If I have some angle 350 degrees and I want to have optimization range +-100 degrees, how should I tell it to software? I can not have maximum over 360 degrees and it also do not accept lower values as maximum. It would be more practical also in some other situations, if I could input optimization limits compared to initial guess.

This is already possible. Consider that 350 degrees is also -10 degrees. So to go from -10 +/- 100, your bounds would be -110 to 90.

However, there is one aspect I would like to be investigated. To compare the relative speed I made the same flyby with both the algorithms: a "simple" Kerbin-Eve-Duna, same starting condition and initial parameters. The multi algorithm found a different solution, requiring much less DV. Here the screenshots of the two. The plot of the transfer orbits is very similar (though projected to a different angle), and the single flyby plot is more "feature complete" currrently, showing planets positions. But information in the windows to the right is not similar.

So right now, the original FMS didn't actually include anything but the flyby delta-v in it's objective function. MFMS, however, also includes the departure and arrival v-infinity in the objective function. I included it here because I noticed that without it you could get some pretty crazy solutions that were feasible (in the optimization sense) and had no flyby delta-v, but would require TONS of delta-v to depart from Kerbin or whatnot. Basically you could never execute them. I had to add these in to force the solutions to be feasible to execute.

So the reason you're getting different solutions is that it's two different objective functions. It's a good thing, though, that the MFMS found the smaller delta-v solution? That would be progress, no?

Anyway, glad you like it! Maybe I should call the application the "Diomedea Multi-flyby Maneuver Sequencer" since it was your idea...

[diomedea]

...

So the reason you're getting different solutions is that it's two different objective functions. It's a good thing, though, that the MFMS found the smaller delta-v solution? That would be progress, no?

Anyway, glad you like it! Maybe I should call the application the "Diomedea Multi-flyby Maneuver Sequencer" since it was your idea...

That inclusion of v-infinity in the objective function has to be considered a key improvement, I couldn't think the difference being so marked. Definitely, yes, another impressive improvement with MFMS. Another thing to thank you about for having implemented (and thanks to others for their suggestions).

Definitely yes, I like this KSP TOT version a lot. But certainly pressing you about making the MFMS isn't worth a mention, not more than the many others who contributed with their ideas.