Kerbal Space Program Trajectory Optimization Tool

[domox]

I would LOVE to have MechJeb integration. I've actually been thinking about this a fair amount and I think I could pull it off. Of course, I would need R4m0n's help as he would have to parse the data coming out of KSP TOT, be it either a data stream from the application or some type of flat file with the trajectory information in it or something.

Can I assume this is something a lot of people want to see?

Most definitely, and slightly off topic, but would it be possible to create a variant that uses vinti or something similar to generate an intercept path for fast moving short range body intercepts. Or do you think this would be accurate enough if fed appropriate data for the bodies?

[Arrowstar]

Maybe in the future. It's not on the radar at the moment. I still need to get the basic functionality around. Keep your suggestion in mind and I'll take a look at it at some indeterminable time in the future. (Sorry, I know that's a sucky answer, best I can do atm.)

[Arrowstar]

Good news, folks. I found my optimization package! I'm using EvA2, which (when spelled out) is the "Evolutionary Algorithm Workbench." I've been testing it tonight on the Ackley function it's done well. In fact, this package is wonderful because it incorporates a number of different algorithms. I'm actually thinking of going to a particle swarm method instead of GA because it's just done that much better. But we'll see. In any event, I'm feeling better about things on that front. Tomorrow I'll put together the final Flight Plan GUI element and whip up the optimization page and see what happens.

I need a favor from someone, as well... if anyone knows a good Java library that can definitely do contour plotting and can help me with learning how to use it, I would be really really appreciative. I haven't been able to find anything I can understand (mostly because of terrible documentation) and I really need help. At the moment, the best I've been able to find is SGT, but I can't make heads or tails of it. If you can help me, please let me know...

Edited August 17, 2012 by Arrowstar

[Awaras]

Not a dumb question at all! You are correct, KSP TOT does assume impulsive maneuvers. If i wanted to do finite duration maneuvers, the whole problem becomes a lot more complicated to compute. I would have to write the equations of motion of the spacecraft and then integrate those numerically while somehow enforcing the end conditions of arrival and departure at the correct bodies. It would be a nightmare.

Sorry for the offtopic, but this has been bugging me for some time, and I hope you can help me figure it out:

What is the best strategy for non-impulsive maneuvers?

Let's say that you are starting your burn from a perfectly circular orbit. Your ship is pointing toward the intersection between the horizon and the 90 degree marker on the navball. Your ship has very low thrust and will need to burn for a minute or more to get where you are going. Do you:

1. Keep your ship oriented toward your prograde marker

2. Keep pointing toward the horizon/90 degree intersection

3. Keep your original orientation (Keep ASAS on during the entire burn)

My intuition tells me that 1. is the correct answer, but I have never been 100% sure.

[togfox]

Wish i can help with the java stuff but its not my area.

[Arrowstar]

Sorry for the offtopic, but this has been bugging me for some time, and I hope you can help me figure it out:

What is the best strategy for non-impulsive maneuvers?

Let's say that you are starting your burn from a perfectly circular orbit. Your ship is pointing toward the intersection between the horizon and the 90 degree marker on the navball. Your ship has very low thrust and will need to burn for a minute or more to get where you are going. Do you:

1. Keep your ship oriented toward your prograde marker

2. Keep pointing toward the horizon/90 degree intersection

3. Keep your original orientation (Keep ASAS on during the entire burn)

My intuition tells me that 1. is the correct answer, but I have never been 100% sure.

Depends on how low your thrust is. In reality, it's likely that none of those options are actually correct for true low-thrust missions. Low-thrust trajectory design is very complicated and can't be simmered down to a solution as straight forward as those you presented.

From here on out, let's try to keep this thread on topic, please.

Wish i can help with the java stuff but its not my area.

That's fine... if you know anyone who does know Java, send them my way.

[Arrowstar]

So, funny story. It turns out that the Lambert solver I was using prior to today only had the ability to solve for elliptical transfer orbits. Now, it just so happens that if you want to go from the Mun to Minmus, you aren't getting there on an elliptical transfer arc: the gravitational parameter of Kerbin isn't large enough to make that feasible unless you really design for it at very contrived points in time. What does this mean? It means that as of this afternoon I have written a (sort of) working Battin Lambert solver in Java using Vallado's wonderful "Fundamentals of Astrodynamics and Applications" as a reference. This solver is FAR more robust than what I was using before (which was based off JAT, a package I no longer recommend using for that very reason). My JAT solver was dying every two or three runs. My Battin solver has handled everything I've thrown at it without a problem (though some near-parabolic transfers cause it to slow down a bit). Part of that is the robustness of the underlying method and part of that is the robustness of the Brent root-finder I'm using from the Apache Math Commons library.

Anyway, long story short, I'm getting closer to a 0.1 release. Major technical hurdles are being overcome. It's been a productive day.

[togfox]

Make sure you dont break your calculator doing all that math ...

[Arrowstar]

Plots tab:

Edited August 19, 2012 by Arrowstar

[togfox]

thats looking pretty spiffy

[Arrowstar]

Here's an updated shot of the C3 plot tab:

Controls have been added to the left side that allow the user to select the two bodies to compute departure to and from. Controls for the range of dates of departure and arrival have also been put in. Users can also specify how many points along the axis they want computed.

I'm going to add the synodic period of the two selected bodies into the display somewhere. This will give users an idea of how large their analysis windows should be to cover the full trade space.

A quick note about the plot: the reason the lower right corner is all red is because that segment contains all those flight plans where the arrival time is before the departure time. Since this is impossible, my code skips those "trajectories" and assigns them some maximum value that the user will specify (still need to add to the window).

I still need to get my Lambert solver working fully, but once that's up and running and this C3 tab is up and running, I think we'll be good to go for a 0.1 release. Probably won't happen this weekend, however. Sorry, togfox.

[togfox]

No rush. I assume the black in the top left corner signifies an almost energy-free trajectory?

[Arrowstar]

Half-correct. It signifies that almost no energy beyond that needed to escape the Mun's gravity well is needed to arrive at Minmus.

Btw, note that since my Lambert solver is giving blatantly wrong results right now, that graph is not correct. The actual result will probably look more like a traditional porkchop plot. Though this is KSP...

Edited August 20, 2012 by Arrowstar

[togfox]

Have you reached the point yet where peeps can enter their own celestial bodies and create pork chops off that data? I say this as we'll soon have extra planets and moons to travel to and if peeps can enter their own celestial parameters then they won't be dependent no you for a hardcoded update.

It might have other unexpected spin off's. I might like to do a pork chop on how to intercept my non-geostationary spacedock that is circling Kerbin.

[Arrowstar]

That feature is definitely in the plans for some point. However, there's a lot of extra GUI work involved in pulling that off, I suspect, and I really need to get core features working before I can do that. However, it is something I will get to, yes. I just can't tell you when that's going to be.

[HalcyonSpirit]

Well, looks like you're well on your way toward getting this program operational. Good work so far.

Of course, I'm half sad that that's the case, since yesterday I decided I wanted to create a program like this myself. Figured it'd be useful to the community with the upcoming update, and it'd also let me review my Astrodynamics coursework from my aerospace undergrad classes. But sure enough, I come here to see if anyone's done anything similar and here you are creating a program that appears to be more intricate than what I had in mind for my own. A lot further along and using algorithms much more efficient than anything I could probably come up with, too (not exactly trained in coding, just the underlying basics of astrodynamics and enough coding ability to put something together). AND in the more universal Java language, rather than my MATLAB-based program I had planned.

Sad day for me, but good work on what you've done so far (from what I can see, anyway). Any thoughts on the kinds of pitfalls and surprises you've encountered when coding your program? I'm most interested in the actual orbital mechanics stuff as far as that goes.

[togfox]

Welcome to the forum. It sounds like you're the perfect beta tester for this.

[Arrowstar]

Well, looks like you're well on your way toward getting this program operational. Good work so far.

Of course, I'm half sad that that's the case, since yesterday I decided I wanted to create a program like this myself. Figured it'd be useful to the community with the upcoming update, and it'd also let me review my Astrodynamics coursework from my aerospace undergrad classes. But sure enough, I come here to see if anyone's done anything similar and here you are creating a program that appears to be more intricate than what I had in mind for my own. A lot further along and using algorithms much more efficient than anything I could probably come up with, too (not exactly trained in coding, just the underlying basics of astrodynamics and enough coding ability to put something together). AND in the more universal Java language, rather than my MATLAB-based program I had planned.

Sad day for me, but good work on what you've done so far (from what I can see, anyway). Any thoughts on the kinds of pitfalls and surprises you've encountered when coding your program? I'm most interested in the actual orbital mechanics stuff as far as that goes.

Sorry for stepping on your toes! I've wanted to do this with KSP for a while now, but it only became sensible after the 0.17 change log was released. You've asked a number of questions, let me tackle them in parts.

The biggest pitfalls for the program have included finding good optimization, math, and Lambert solver packages. For the latter, I actually ended up writing my own since the Lambert solver included in JAT is garbage. My optimization algorithm is a genetic algorithm written in the EvA2 library, and the math library is Apache Commons Math. I could have written the genetic algorithm myself if I wanted, but global optimization is a field I've only had a bit of exposure to, whereas astrodynamics is my life. I've also implemented Lambert solvers before, so I (basically) knew what I was doing. It still has a bug somewhere in it, but I've got the requisite textbook on order, so I'll squash that this week/weekend. Yes, that's right, I ordered a textbook to help me write this program.

There haven't been too many surprises, to be honest. I suppose the big one is the complete lack of good contour plotting packages available for Java. Im using SGT right now, but it's not very feature-rich. I can't comment on any of the astro aspects yet, because I don't have a working Lambert solver, but I'm expecting to find some cool things once I go through and start looking at optimal solar system geometry for planetary tours. Heck, even the Kerbin system (Mun and Minmus) should even have a surprise or two in the pork-chop plots. Or so I hope!

Btw, this is not a program you want to do in MATLAB. Oh sure, MATLAB is awesome as a computational toolbox and for that I love it dearly. But if you're going to distribute code, you need to give people the Matlab Compiler Runtime, which is 330 MB. It is not a good thing to distribute. I've written a program just like this one for Orbiter in MATLAB (called, interestingly enough, TOT) and the MCR was the worst part of it.

If you'd like to a beta tester, let me know via PM or something. I'd love to have another person taking a look and it sounds like you have the requisite engineering background. Let me know if you have any other questions about the program, it's fun to talk about!

Welcome to the forum. It sounds like you're the perfect beta tester for this.

Agreed!

[togfox]

I just remembered the telemetry plugin has graphs done in java. Line graphs . I guess your past that by now but thought id suggest that one.

[Arrowstar]

Line charts aren't too bad, there are lots of libraries that can do those. If I need a line graph, I'll probably go with JavaFX, it looks pretty nice. The problem is contour plotting: almost no one has an easy to use plotting tool out there for contours. The only one I was able to find is SGT, but there are a lot of features I think it misses, such as grid lines and the like. Oh well, not a big deal of course.

Do you know, by any chance, which packages the telemetry mod uses? Thanks for pointing this out!

[HalcyonSpirit]

I'm of course interested in beta-testing, but I'm also wary of the fact that I saw you use terms like "genetic algorithms," "porkchop plots" and "Lambert solvers" and all I could keep thinking to myself was this. Of course once I pulled out my notes from my classes I recognized the Lambert stuff, and I know the ideas behind most everything else that you've mentioned once I remembered them, but my lack of real-world experience with the stuff does show... (More than two years out of college and I still can't land an aerospace-related job. Blah, stupid economy.) It probably wouldn't be hard for me to quickly pick up what you're doing, but I just wonder how useful I'd be despite that.

Regardless, I'll send you a PM about it. If nothing else, there'd be a lot for me to learn from it, and I may be able to pick up on any possible non-obvious errors.

I think I'm going to try my hand at writing something as well, if only for myself to brush up on what I already know and expand my ability from there. Probably won't hold a candle to yours for a long time, since I had planned on making mine a simple brute-force type solver initially before improving with optimizations and such. Still, gotta start somewhere.

Heck, maybe I'll be ordering textbooks on the subject by the end of it as well! What text did you order, anyway?

[Corax]

I just remembered the telemetry plugin has graphs done in java. Line graphs . I guess your past that by now but thought id suggest that one.

It's a common misconception that the telemetry plugin does any graphing. Its only job is to send data across the network.

I guess what you have in mind is "Elderberry Ni", an addon to the plugin that takes the data and pretty-prints it, so to speak. You can basically do the same stuff with gnuplot, or Excel, or any other graphing software, Elderberry is just a user-friendly interface to the data that does the "heavy" lifting.

Which (kind of) answers the following question:

Do you know, by any chance, which packages the telemetry mod uses? Thanks for pointing this out!

None, it is a C# plugin to KSP that uses functions exposed by Unity and KSP. From what I've seen, Warringer uses AWT for his graphs.

[Arrowstar]

I'm of course interested in beta-testing, but I'm also wary of the fact that I saw you use terms like "genetic algorithms," "porkchop plots" and "Lambert solvers" and all I could keep thinking to myself was this. Of course once I pulled out my notes from my classes I recognized the Lambert stuff, and I know the ideas behind most everything else that you've mentioned once I remembered them, but my lack of real-world experience with the stuff does show... (More than two years out of college and I still can't land an aerospace-related job. Blah, stupid economy.) It probably wouldn't be hard for me to quickly pick up what you're doing, but I just wonder how useful I'd be despite that.

Regardless, I'll send you a PM about it. If nothing else, there'd be a lot for me to learn from it, and I may be able to pick up on any possible non-obvious errors.

I think I'm going to try my hand at writing something as well, if only for myself to brush up on what I already know and expand my ability from there. Probably won't hold a candle to yours for a long time, since I had planned on making mine a simple brute-force type solver initially before improving with optimizations and such. Still, gotta start somewhere.

Heck, maybe I'll be ordering textbooks on the subject by the end of it as well! What text did you order, anyway?

You definitely won't require a graduate-level astrodynamics background in order to beta-test this program. Right now it doesn't even do that much, to be honest. What I'm really looking for are people who know a bit about spaceflight (which I think you do) and are capable of giving constructive, useful feedback. I need people to tell me if the program is user-friendly, if the results it provides are correct, and things like that. I can only do so much testing on my own, which is where beta testers come in.

Regarding your knowledge... you may want to hold off on starting your own program until you have a handle on at least solving Lambert's problem. You will need that if you are going to compute trajectories at all. In addition, the "brute force" technique will not get you very far for optimization, so you may want to look into some algorithms for that. Sadly, standard first order techniques tend to do poorly for trajectory optimization because of the numerous local minima in most cost functions. You'll need a global technique, like genetic algorithms, to really get good results. I should point out that helping me out with KSP TOT would be a good way to introduce yourself to these topics, if you're interested, since I'm implementing them all right now.

Oh, the book I ordered was "Fundamentals of Astrodynamics and Applications" by Vallado. No astrodynamicist should without it, it's a truly excellent reference and many of the algorithms needed by astro engineers are given in "algorithm" form, meaning you should just have to write the code without too much understanding of what the algorithm is actually doing. I recommend it! Make sure to get the third edition, the first two had some errors in it, I guess. The first edition was particularly full of errors, I'm told the list of errata is extensive.

If you have any other questions about the technologies or algorithms I'm using here, please do ask. This offer is, of course, open to anyone with some curiosity, not just HalcyonSpirit.

Did you still want to help beta test then?

[HalcyonSpirit]

Yeah, sure, I'll have a go at it. And thanks for the book ID, I'll probably be getting it sometime regardless of what I end up doing. Even though I'm not in the industry yet, aerospace is where I want to be, and astro stuff is my big interest.

As far as my program goes, no point in worrying about the complicated issues until the fundamentals are implemented. Those are easy enough, though I do need to figure out a more general transfer orbit function than the ones I currently have.

[Arrowstar]

Alright, sounds good. And if I can help in any way with technical questions, let me know.