Kerbal Space Program Trajectory Optimization Tool

[Arrowstar]

Good news, everyone, I got my Lambert solver working. An hour with Vallado's text was all it took. The porkchop plots are coming along nicely and I hope to have something "releasable" this weekend. The program won't be pretty and it won't have any of the trajectory visualization I'm planning on, but it'll at least be capable of optimization and displaying porkchop plots.

Woot!

EDIT: Here's a picture of the pork-chopper in action for my Earth-Mars system that I've got set up in the software. Notice the similarity to the plots I showed in the first post of this thread.

Now that I've got some orbital information for Eve, who wants to see some data on a Kerbin-Eve transfer, eh?

EDIT 2: And here you are. I pulled out the time scale a bit so that you could see the repeating pattern of the launch windows. Cool, huh? Notice how big those pork-chops are... Harv and Co, whether they intended to or not, have really made it pretty easy to hit other planets.

(Don't mind the artifacts in the image, I'm still working on cleaning up the plotting algorithm. You can see, however, that the computational side of things is basically done.)

Btw, I'd like opinions: do people like the time to be entered and displays in units of days or seconds? Seconds are what is in the SFS files, but days make the numbers smaller. Any comments on that?

Edited August 24, 2012 by Arrowstar
Added plot

[togfox]

Looking good. . How are the celestial bodies configured? Are orbital details hardcoded? Can we add our own via interface or cfg file?

I guess if axis displays "days from now" then that makes it easy to know how far to warp. .

[pina_coladas]

Why not both days and seconds? It could be configurable.

I'm really curious about what you're planning for those other tabs like flight planner and trajectory viewer. That's when it gets real

[Arrowstar]

Looking good. . How are the celestial bodies configured? Are orbital details hardcoded? Can we add our own via interface or cfg file?

I guess if axis displays "days from now" then that makes it easy to know how far to warp. .

At the moment, celestial bodies are hard-coded in their own class (called "SolarSystem"). I know you want to be able to make your own, and that'll be higher up on the priority list now. I'm really trying to get the core features right now, though, so I probably won't have that in the 0.1 release (which should be this weekend). It'll get written soon, I promise.

Why not both days and seconds? It could be configurable.

I'm really curious about what you're planning for those other tabs like flight planner and trajectory viewer. That's when it gets real

I'd rather not make the units configurable. It's a pain right now to convert everything as it is, and configurable units would surely make it worse. Of the two, if you had to pick one, would you have a preference?

The flight planner will allow you to set up departure, gravity-assist maneuvers, and arrival at bodies of your choice. I'll show some screenshots later tonight, perhaps. The trajectory viewer will be just that: a way to view the trajectory that you've created. It'll be a simple 2D display at first and I'll add more later (perhaps even going 3D... that'd be wild).

Thanks for the comments, folks.

[Arrowstar]

One more picture before I go to bed. I finished up the plots tab tonight, and I'm going to work on some rudimentary optimization options tomorrow (right now it's a button in the middle of the panel labeled "jButton1" lol). I've got the core optimization code working though, and I cleaned up a number of bugs in the process. Planning on releasing 0.1 either Saturday or Sunday.

(Btw, to clarify, Eve here uses the elements that Nova posted in another thread the other day.)

[Arrowstar]

Hi everyone!

I've finished up 0.1 and have posted here for testing:

https://dl.dropbox.com/u/29126891/KSP%20Trajectory%20Optimization%20Tool.zip

Download the ZIP file, unzip it to its own directory, and doubleclick the JAR file. NOTE: You MUST have the Java Runtime Environment (JRE) version 1.7 (or version 7, they're the same thing) installed for this to work.

Please post constructive comments and feedback here. Note that this is a work in progress, so not everything works or works fully. The porkchop plot is good to go, aside from bugs, but everything else needs more work.

Things that don't work at all: trajectory viewer, optimization report.

Things that partially work: flight plan optimization.

Things that SHOULD work: porkchop plots

Please post your feedback. If you find a bug, tell me how to reproduce it completely. Other comments and suggestions welcome.

Thanks!

Edited August 28, 2012 by Arrowstar

[togfox]

D/l with Java 7 update 5 - 32 bit. Plot working. Shall play. Hard to test the formula's without another body of course.

[Arrowstar]

Agreed. For now, try to just get me feedback on usability bugs, or things that don't work but should, and the like. We'll do full up testing on the algorithms once 0.17 is released and we have a solar system to play around with.

[pina_coladas]

Minor question: is there supposed to be a 50% CPU usage cap on this? Or could it be due to some weird java setting on my end...

[Arrowstar]

Yes, most likely. The calculations are all single-threaded, so if you have a multi-core processor, you'll only see them executed on one processor.

[pina_coladas]

When I check task manager it looks like TOT is using a bit of both cores, yet remains locked at 50% usage, not maxing out one core like I would expect from something single-threaded and computationally intense like this. That's why I thought it was worth mentioning. Am I the only one?

[Arrowstar]

To be honest, I don't know. Can anyone else comment? This is my first ever Java application, so I'm fairly clueless on complex topics such as threading.

[Arrowstar]

Hi everyone:

Version 0.2 of the KSP TOT is now online and available here. Updates include, primarily, some usability fixes and bugfixes in the code. The same instructions apply for installation as with version 0.1: unzip to new directory, ensure JRE 7 is installed, run JAR. As usual, feedback and comments are much appreciated!

Once I get the porkchop plot working the way I like it, the next item of business will be to write the math that computes the optimal departure from a body to a higher SoI. This means, for example, that if you start in Kerbin orbit and wish to head to Eve, not only will the TOT give you the optimal sun-centered trajectory, but it will also figure out how to depart Kerbin optimally as well. Should be fun!

Edited August 30, 2012 by Arrowstar

[togfox]

i know change logs are boring but they greatly assist with testing as i'll know what has changed and what is outstanding

[togfox]

Just loaded up 0.2 and I like it a lot.

I'm not sure if this is a bug, but when I set min/max days from epoch then the optimal transfer is based on that range. When I zoom in with the mouse, the optimal transfer is still based on the text boxes - not on the new values displayed in the grid. Not a biggy but something to think about.

edit: will this work for a Mun/Minmus transfer if you entered the correct data?

Edited August 30, 2012 by togfox

[Arrowstar]

Hi Togfox:

To answer your questions:

A) It's not really a bug. You computed a transfer for a certain range of arrival and departure dates, and the results area provides the minimums for those ranges. The zooming isn't actually tied to anything. I should actually point out that my plotting library is actually SGT, so I'm somewhat bound by what it can do. I'm not sure I can get it to spit out the zoom range on a plot... but if I can, should I do what you've asked about here?

It will work for a Mun/Minmus transfer. The plots are just going to look funny because the two bodies are fairly close to each other and Kerbin has a pretty weak gravitational parameter, meaning that most of your transfer orbits will be hyperbolic. It's this hyperbolic nature of things that makes the graph look odd.

Please let me know about any other bugs or suggestions you have. Thank you!

[HalcyonSpirit]

I'm not sure I can get it to spit out the zoom range on a plot... but if I can, should I do what you've asked about here?

If you can, it might be a good idea. There's a bit of an expectation in some parts that that's how things work. With certain graphs, people expect the results to be based on the graph's limits, so a recalculation is necessary for that. However, that's up to you. The real question is what you think will be more useful for the people using the program: having increased resolution or increased breadth of options in the displayed results by zooming, or having a quick way to change the area of results based on an initial calculation? If you have to choose just one, this has to be considered.

[Arrowstar]

I should have another testing release out tomorrow with a change log included. Work mostly concentrated on getting the optimization program running and on the whole it's almost there. I did a good chuck today, and now the program will populate a report field that provides all sorts of information regarding the results of the optimization run. Of course, until we get planets, this will be a bit useless, but it's fun to play around with anyway.

[silent_prtoagonist]

I'm getting an error that says "Unable to load JavaFX runtime" when I run the .jar. This happens with both version 0.1 and 0.2. I'm running Java 7 Update 7 (7.0.70) 32 bit on Windows 7 Pro x64. I also ran into this problem running 64 bit java.

[Arrowstar]

Hmm, that's interesting. JavaFX *should* be contained in the main JAR file. Has anyone else gotten this error? Silent, can I assume you're on Win7 64-bit?

[silent_prtoagonist]

Yea, I'm on Win7 64-bit

[Arrowstar]

Alright, version 0.3 is now available here!

Change log:

-Created optimization report for optimization runs

-Removed PBIL optimization algorithm, was causing problems.

-Removed dependency on JavaFX (fixed Silent's bug, so far as I can tell)

-Found a few bugs with the code that computes C3 energy and arrival velocity, fixed them.

-Some internal documentation for my own benefit.

As usual, comments, suggestions, and constructive criticism are most welcome!

Btw, I've not yet had a chance to investigate getting the zoom range on the plot, but I'll keep working on it. Please let me know what you guys think of everything else in the mean time.

[silent_prtoagonist]

Yep, that fixed it, working great for me

[Nadrek]

First, thank you very much for building this, and referencing the Vallado book - I knew I'd barely started, but now I know I have not even set foot upon the path.

I'll certainly be willing to help out with Autom8 integration of some sort, though my initial thoughts would be to leverage and extend the functionality I'm already building (http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962).

Let me know your thoughts on this, but I'd expect that the simplest way to start integration off, have the TOT write out an Autom8 script that executes the various parts at whatever level of detail we reach in the middle. Eventually, I'd hope to create the capability within Autom8's lua to perform more and more of the orbital mechanics and operations directly, which would allow the TOT to do better optimization and all the graphs, then based on user selections in the graphical TOT module give a very simple, readable lua script, specifying the orbital transfers, while the lua code does a lot of the determinations on attitude adjustment for each burn - i.e. feed Autom8 the optimal/chosen orbital path, and let Autom8 do the calculations for how to get onto it.

Note that this is my first and only lua project, and my first and only orbital mechanics and astrodynamics project, so it'll take me awhile to get anywhere meaningful - and I'm trying to document as I go, which takes time up front. Anyone else wanting to jump in, with or without bootstrapping off the code I'm writing (anything protectable is under GPLv2, GPLv3, and/or CC BY-SA 3.0 Unported - math, of course, is not protectable), is more than welcome to. Also, I have never touched Java, either, but I was once quite comfortable with C.

Any assistance or good references on the various and sundry reference systems available, and which are best for what purposes, would be more than welcome.

P.S. Since KSP operates in seconds, seconds are essentially the fundamental time unit, are much finer grained than a 'day', have no confusion about which celestial body's 'day' it is or what rotation period to use, and are not subject to occassional calendar-correcting chagnes, I would very seriously recommend seconds instead of days.

[Arrowstar]

Nadrek: I would love to work with you. I'll shoot you a PM with details and questions, but I am super excited about this.

EDIT: All calculations are done in seconds, but I output days because the numbers are smaller and better suited to graphs and reading. Also, a day is defined as 86400 seconds by my book. ;-)

Edited September 5, 2012 by Arrowstar