[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[MaverickSawyer]

Very slick. Much more intuitive than what I had in mind. Can't wait to see this in action!

[bk2w]

I just uploaded v0.11.2 which should resolve the remaining plotting issues. Could you check it out and take a look to verify? It all works on my end now.

It seems that the source code in the package did not get updated along with the executable. I'm seeing the .exe report itself as version 0.11.2, but the source code (and anything I compile from it) reports as 0.11. Can you verify that the archive on the OP has the correct source code?

I've been recompiling each of these subversions for OSX and they've all been behaving well.

-Brian

[Arrowstar]

It seems that the source code in the package did not get updated along with the executable. I'm seeing the .exe report itself as version 0.11.2, but the source code (and anything I compile from it) reports as 0.11. Can you verify that the archive on the OP has the correct source code?

I've been recompiling each of these subversions for OSX and they've all been behaving well.

-Brian

Huh, you're completely right, I did forget to update the source code. I've just uploaded a new package for 0.11.2 that has that source code in it. Can you give it a try and see if that's more to your liking? Sorry about that!

[Billy-Bobbart Kermân]

This is a great piece of work! Just a suggestion on the instructions though - I spent HOURS trying to get it to work before I found a post mentioning to copy the KSPTOTConnect folder to KSP's Gamedata folder. Should have been obvious I suppose, but may be worth while to put it in the instructions. Just a suggestion!

Installation Instructions

To install and run KSP TOT, do the following:

1. 
   [*=left]Download the

Windows 32-bit 2013a MATLAB Compiler Runtime (MCR).
[*=left]Install the MCR package on your computer.
[*=left]Download the KSP TOT package.
[*=left]Unzip the KSP TOT package to a directory of your choosing.
[*=left]Copy the KSPTOTConnect folder to your KSP Gamedata folder.
[*=left]Run the KSPTOT application.
[*=left]To update from a previous version, just repeat steps 3-5. There is no need to re-download the MCR.

[billeinstein]

I want to use this tool for RealSolarSystem mod. Then I should build a new bodies.ini file.

But I need some help. For Example

[Kerbin]
epoch = 0
sma = 13599840.256
ecc = 0
inc = 0
raan = 0 
arg = 0
mean = 179.908747671079
gm = 3531.6
radius = 600
atmoHgt = 69.077553
bodycolor = winter
canBeCentral = 1
canBeArriveDepart = 1
parent = Sun
name = Kerbin
id = 1

Kerbin
	{
		SSTScale = 1
		Radius = 6371000
		rotationPeriod = 86164.0916
		tidallyLocked = false
		axialTilt = 23.44
		atmosphereScaleHeight = 7.5
		maxAtmosphereAltitude = 104000
		Orbit
		{
			semiMajorAxis = 149598261000
			eccentricity = 0.01671123
			inclination = 0
			meanAnomalyAtEpochD = 357.51716
			period = 31558149.7635456
			LAN = 348.73936
			argumentOfPeriapsis = 114.20783
		}
......

How to apply this "axialTilt = 23.44" in bodies.ini? Or shall I ignore it？

[Arrowstar]

This is a great piece of work! Just a suggestion on the instructions though - I spent HOURS trying to get it to work before I found a post mentioning to copy the KSPTOTConnect folder to KSP's Gamedata folder. Should have been obvious I suppose, but may be worth while to put it in the instructions. Just a suggestion!

Done! Great suggestion, thanks for thinking of it. I completely forgot to update my install instructions.

I want to use this tool for RealSolarSystem mod. Then I should build a new bodies.ini file.

But I need some help. For Example

<snip>

How to apply this "axialTilt = 23.44" in bodies.ini? Or shall I ignore it？

Sadly, you'll have to ignore. KSP TOT and stock KSP do not handle axial tilt at the moment, so I don't have any reason to work with that kind of thing. Sorry!

[Garek]

I don't have MechJeb and for node input I would like to use PreciseNode. That doesn't have the snap-to-node + shift-time functions MechJeb has, but rather a plain simple UT input field. So would it be possible to output the UT for the burns?

EDIT: so it seems PreciseNode actually has some additional time controls which would make burn time after Periapsis work. Nevertheless I would apreciate a UT output there, if it's not to complicated to do.

Edited January 19, 2014 by Garek

[Arrowstar]

I don't have MechJeb and for node input I would like to use PreciseNode. That doesn't have the snap-to-node + shift-time functions MechJeb has, but rather a plain simple UT input field. So would it be possible to output the UT for the burns?

EDIT: so it seems PreciseNode actually has some additional time controls which would make burn time after Periapsis work. Nevertheless I would apreciate a UT output there, if it's not to complicated to do.

In general, it is not possible to know the precise UT to place the node at. This is because, while the time of the optimal maneuver might be known, the position of the vehicle in it's orbit and the epoch of that position is typically not a required parameter for most analyses. The time of the maneuver varies slightly when this is taken into account.

In short, use the "time past periapse" for placing nodes, it's much cleaner and does not require additional information to compute.

[Garek]

In general, it is not possible to know the precise UT to place the node at. This is because, while the time of the optimal maneuver might be known, the position of the vehicle in it's orbit and the epoch of that position is typically not a required parameter for most analyses. The time of the maneuver varies slightly when this is taken into account.

In short, use the "time past periapse" for placing nodes, it's much cleaner and does not require additional information to compute.

Okay, that makes sense. Because of...stuff it will be wednesday before I get back to the game, but then I will try to make it work with the additional UT controls I found in PreciseNode. I guess that should work

[Arrowstar]

Okay, that makes sense. Because of...stuff it will be wednesday before I get back to the game, but then I will try to make it work with the additional UT controls I found in PreciseNode. I guess that should work

Great! Let me know how it goes.

[FanaticalFighter]

This has to be the best thing I've discovered for KSP. Arrowstar - you are AWESOME.

I have a few questions:

1. How do I calculate free-return trajectories to the moon?

2. Any way to calculate flybys of Joolean Moons? As in, I go to the Jool, and then find the best way to get flybys from moons with the least amount of dV possible?

3. How can I get the true mean anomaly for maneuver execution assistant? Sometimes, my burns can be long, and this tool would really come in handy then, but I have no clue how to grab a maneuver's true mean anomaly (KSP stores maneuvers through time, not TMA)

[Arrowstar]

This has to be the best thing I've discovered for KSP. Arrowstar - you are AWESOME.

Thanks! I really do like hearing that people enjoy using something that I've poured hundreds of hours into over the past year. Makes me all warm and fuzzy inside.

1. How do I calculate free-return trajectories to the moon?

At the moment, I don't actually have this math in KSP TOT. Not that I couldn't (there an analytical solution if you know how to set it up properly), but no one's ever asked before. I would use the rendezvous planner, target the Mun, and then in KSP, change the delta-v just a bit using a maneuver node editor plugin (in prograde direction and time) until you get what you want.

2. Any way to calculate flybys of Joolean Moons? As in, I go to the Jool, and then find the best way to get flybys from moons with the least amount of dV possible?

The fly by maneuver sequencer should be able to help with this. Give it a go and let me know what questions you have.

3. How can I get the true mean anomaly for maneuver execution assistant? Sometimes, my burns can be long, and this tool would really come in handy then, but I have no clue how to grab a maneuver's true mean anomaly (KSP stores maneuvers through time, not TMA)

I'm running to work at the moment; I'll investigate tonight. Remind me if I don't get back to you by tomorrow.

[billeinstein]

Off-plane trajectories (two impulse Lambert solutions) sometimes may not be good enough. The calculation can get a high inclination eject trajectory which needs more dv. It will be better if it can optimize the transfer trajectories with DSM (Deep Space Maneuvers) sometimes. Such as source plane transfer in the IMFD of Orbiter.

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19940010378_1994010378.pdf

Another example is this web planner (transfer type)：

http://alexmoon.github.io/ksp/

[Arrowstar]

Off-plane trajectories (two impulse Lambert solutions) sometimes may not be good enough. The calculation can get a high inclination eject trajectory which needs more dv. It will be better if it can optimize the transfer trajectories with DSM (Deep Space Maneuvers) sometimes. Such as source plane transfer in the IMFD of Orbiter.

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19940010378_1994010378.pdf

Another example is this web planner (transfer type)：

http://alexmoon.github.io/ksp/

Hi! I've considered implementing DSM code, but decided against it because in most cases the ballistic trajectories TOT already gives you are good enough (in short, not enough unique utility). Thanks for the suggestion, though!

(Though I should point out that if you would like to PM me with a link to some working DSM maneuver code, I'll certainly take a look again.)

[Arrowstar]

Hey everyone!

Tonight I want to share what I've been working on for the last week. It's really bugged me for a while now that, while KSP TOT has lots of great features and algorithms, none of those things really talk together. Thus, to date, KSP TOT is a great maneuver planner, but what it's not is a great mission planner. This goes beyond just the basic engine burns; considerations such as propellant margins and mission duration are also important for the KSP (and real life) mission designer.

When I started KSP TOT awhile ago, I set out of offer the premier KSP mission design software available from anyway. On the whole, it's been a resounding success. But as I noted above, it can go farther. Thus, tonight I present what I'm calling the KSP TOT Mission Architect.

Mission Architect is designed to be a full-up mission planning suite that leverages all the other tools KSP TOT makes available. It will allow the KSP mission planner to see the full scope of the mission they will execute, from initial parking orbit to final destination.

A few features to point out:

On the left of the window, above, is the mission event list. The mission event list includes all the events that Mission Architect will propagate through. Events include coasts (propagating without engines running), maneuvers (adding delta-v), and mass dumps/staging. As the event list is updated, Mission Architect automatically recomputes the impact of the changes on the mission. To add events, simple select the event type from the drop down box. A window will appear, prompting for details of the event. Provide them and the event is added to the list. To edit an event, just double-click the entry mission event list. It's quite slick.

Next to the mission event list is the state summary. The initial and final states and shown, and viewing state summaries at other points in the mission will be possible, too. In addition, a full reporting and graphing suite will be available.

Finally, on the right is the orbit view. This segment works like the rest of KSP TOT, but as orbits here can extent over multiple bodies and spheres of influence, some additional GUI work was needed (read: arrow buttons) so users can flip between them all.

Some other features that I haven't started yet, but plan to include:

1) Auto Lambert targeting of orbits;

2) Optimizer integration for meeting mission objective and satisfying mission constraints; and

3) Some nice plotting and reporting tools.

From above, here's an example of what the Insert Coast dialog box looks like:

Most of the past week was spent designing and implementing a super flexible scheme for propagating through events of all types, be they coasts, dv maneuvers, or whatever. Friday and today I implemented the GUI as you see it. I'm hoping to have a good chunk of it done by the end of the weekend. Mission Architect will be the primary release feature of KSP TOT v0.12.

Right, so, questions/comments? I'm eager to know what you all think of Mission Architect. I think it's going to be pretty nifty, and I'm looking forward to giving it to the larger KSP community soon!

[diomedea]

Right, so, questions/comments? I'm eager to know what you all think of Mission Architect. I think it's going to be pretty nifty, and I'm looking forward to giving it to the larger KSP community soon!

Better than awesome, I can't even think of an adequate term for Mission Architect.

I am doing that all by hand, careful checking all needed data and computing what I need in terms of Delta-V for any of the maneuvers, planning them all before launch to be safe I can complete a mission.

I am really looking forward to it, to being able to use this masterpiece of software you are creating.

[drtedastro]

Finally, YEEEESSSSSS.. Great stuff Arrowstar, great stuff. Now the big picture starts to form. Info and data from the MA loaded into a 'mission control' type scenario, where the MA data is used to setup what is 'nominal' and compared in realtime to the actual data. Will be able to determine is we are dead center, shallowing out, etc.... C-O, calculated vs observed...

Thanks for all of your truly great work...

[Galane]

Now if this could tie into MechJeb to feed it data for how and when to make maneuvers, that would enable MechJeb to do things it can't do, such as do transfers at what may be less than optimal times, or plot a course from moon orbits to places other than the planet the moon is orbiting.

A Mun orbiting station has limited utility if you can't take off directly from it to Minmus or anywhere else other than back to Kerbin orbit. It's like going from BOI to DTW by way of SEA instead of flying direct to DTW - wit Mun as Boise, Kerbin as Seattle and Minmus as Detroit. "But I need to fly EAST! Why do most flights from here go WEST first?"

[Arrowstar]

Better than awesome, I can't even think of an adequate term for Mission Architect.

I am doing that all by hand, careful checking all needed data and computing what I need in terms of Delta-V for any of the maneuvers, planning them all before launch to be safe I can complete a mission.

I am really looking forward to it, to being able to use this masterpiece of software you are creating.

Thanks! Yep, Mission Architect should be quite good at what you just described.

Finally, YEEEESSSSSS.. Great stuff Arrowstar, great stuff. Now the big picture starts to form. Info and data from the MA loaded into a 'mission control' type scenario, where the MA data is used to setup what is 'nominal' and compared in realtime to the actual data. Will be able to determine is we are dead center, shallowing out, etc.... C-O, calculated vs observed...

Thanks for all of your truly great work...

Totally.

Now if this could tie into MechJeb to feed it data for how and when to make maneuvers, that would enable MechJeb to do things it can't do, such as do transfers at what may be less than optimal times, or plot a course from moon orbits to places other than the planet the moon is orbiting.

A Mun orbiting station has limited utility if you can't take off directly from it to Minmus or anywhere else other than back to Kerbin orbit. It's like going from BOI to DTW by way of SEA instead of flying direct to DTW - wit Mun as Boise, Kerbin as Seattle and Minmus as Detroit. "But I need to fly EAST! Why do most flights from here go WEST first?"

The other applications in KSP TOT, an option exists to "Upload a Maneuver" to KSP directly, if you have the KSPTOTConnect plugin running with KSP. This will create a maneuver node in the game. Just have MechJeb execute the node you create via upload. Viola. (Right-click on any text box with maneuver/burn information and click "Upload Maneuver" or some such thing to actually do this.)

Made some good progress last night. Mission Architect is now capable of adding/editing/removing events from the mission list and propagating through them all. The output window is mostly working and plotting has been improved a bit. Next up will be the optimizer, followed by general 2D plotting of useful quantities w.r.t. time (mass, orbital elements, etc). We might be go for a pre-release after that gets done (maybe by the end of this weekend - we'll see). There will be bugs, to be sure, best way to squash them is to give this to others and let them have at it.

I got a few PMs over the last two days - if you're still waiting to hear back from me, I'll get back to you tonight.

[tavert]

As an update on attempting to build this on Linux, I finally sorted out my Matlab license situation for the new year and installed R2013a on a Linux machine.

First issue was the Lambert solver, as bk2w saw on Mac. The recommended emlmex call to compile lambert.m into a mex file doesn't work in R2013a since emlmex is obsolete, but it did work in R2009b to generate a lambert.mexa64 which appears to work fine in newer versions of Matlab. When I run projectMain.m in Matlab R2013a after compiling lambert.mexa64 (and renamed lambert.m to something else for testing purposes), the basic Kerbin-Duna porkchop plot appears to work. Don't have much time to test other features.

So then I tried deploytool to build the standalone application. It appears the Matlab Compiler is very buggy in R2013a on Linux, see http://www.mathworks.com/matlabcentral/answers/98190 and http://www.mathworks.com/support/bugreports/951485. I'm running into the same error as in those posts:

Depfun error: 'Unexpected Standard exception from MEX file.
What() is:
..'

Tried the suggested workaround replacing depfun.opts, didn't fix the error. The error occured in the deploytool Build window after "Processing /opt/matlab2013a/toolbox/shared/instrument/mcc.enc", so I suspect it might be Instrument Toolbox - related. I might still have a copy of KSPTOT 0.10 lying around, I may try building that to see if it runs into the same error. Otherwise I don't have a lot of time to keep messing around with this, sorry.

[bk2w]

Is there someway to get detail of the final injection burn for either the Fly-By Sequencer or the main Transfer tool? Both tools give me departure burn information, and it's apparent that they're optimizing for departure+injection, but the lack of injection burn information is making it difficult for me to plan some missions for lack of how much delta-v I need for the full mission.

-Brian

[Arrowstar]

Tavert: Okay, no worries. Feel free to try with a different version of MATLAB if you think that would help. If not, then don't worry about it. Thank you for trying!

Is there someway to get detail of the final injection burn for either the Fly-By Sequencer or the main Transfer tool? Both tools give me departure burn information, and it's apparent that they're optimizing for departure+injection, but the lack of injection burn information is making it difficult for me to plan some missions for lack of how much delta-v I need for the full mission.

My "injection burn" do you mean the "insertion burn"? That is, the burn needed to stop at a particular planet/moon? Afraid I can't help there, it's not calculated because the insertion orbit isn't calculated. There's a long reason why not, but basically it comes down to too many unknowns in the math to get it working correctly. As an alternative, I would suggest getting your ejection burn set up, then make some assumptions on what you think your hyperbolic arrival orbit will look like at your destination. Then, go to the Optimal 2-Burn Orbit Change application, plug that in as the starting orbit, and plug in your desired final orbit. Do some studies and see what you get for delta-v.

Let me know if that helps or not.

[Arrowstar]

Hi everyone,

Here's what I've been up tonight. The basic mission plan display/edit/propagate is effectively complete. Thus, tonight I started on the other major functionality of KSP TOT Mission Architect: the optimizer. Thus, I present the Mission Optimizer:

So here's the basic idea. It's easy to put together a mission script, but harder to get it to do what you want. For example, say you want to go to the Mun. You can either muck around with delta-v vectors and true anomaly of the burn, or you can tell Mission Optimizer "hey, I'd like to go to the Mun" and, if you word the question correctly, it should figure it out.

Looking at the GUI, it's three parts from left to right. The first is the objective function. This is the "what are you trying to achieve" part. Most of the time, we'd like to maximize spacecraft mass (thus saving fuel), minimize transfer duration, or similar things. These two objectives I've listed here will probably be the only two that come with Mission Architect initially. All objective functions are evaluated at the end of the event you specify for them.

Below the Objective are the Variables. If "Objective" is the what, then "Variables" are the how. These tell the optimizer what to vary (hence the name, variables ) in order to achieve the objective. Here the Mission Optimizer, events in the mission script are varied. This could be the target true anomaly of a coast, the delta-v vector of a burn, or both.

Finally, on the right we have constraints. Constraints allow for you to make sure the optimizer doesn't do things you want it to avoid, or find solutions which are mathematically possible but not physically realizable. Like objective functions, constraints are evaluated after the event that goes along with them.

Savvy planners will use the optimizer in stages to achieve various stages of the mission sequentially. Trying to setup everything at once will be a hassle and the optimization code will probably not like it either. Want to fly by the moon to get to Duna? Set up the Mun flyby first, then target Duna, and so on.

As a note, this is just the GUI design. I'm going to start the actual optimization code tomorrow, though that may just be architecture and the like. There will be separate structures for the objective function, variables, and constraints, all of which need to be worked out in a manner that allows all of them to work together nicely. Oh dear.

So how does that all sound?

[tavert]

Tavert: Okay, no worries. Feel free to try with a different version of MATLAB if you think that would help. If not, then don't worry about it. Thank you for trying!

2012a is the next closest thing I have installed. Had to slightly modify helper_methods/multiStartCommonRun.m to replace optimoptions with optimset, and fiddle with /etc/hosts to avoid a java.net.UnknownHostException. Looks like I got something that is mostly working, I'll PM you a link so you can test in a VM.

[Galane]

It'll be able to figure out the soonest departure time from Duna to Kerbin, with the mass and fuel available, leaving enough fuel to slow down at Kerbin?

It can get back at the optimal time (according to MechJeb) with just four orange tanks with four Skippers. (IIRC it didn't even use all that in testing.) Between those and the lander are another orange and four FL-T800 tanks with a Skipper and four LV-T30 or LV-T45. I can pop loose the middle section, dock the lander to the four oranges, jettison the two power pods and get back using even less fuel.

Burning 100% of those four orange tanks ought to get somewhat of an earlier departure, while leaving the other orange and FL-T800 tanks to slow down into a Kerbin orbit. Doesn't have to be circular or particularly low altitude. The lander is capable of getting down from quite high up.

I overbuilt this ship sooooo much! Math? What math? Just put together *enough fuel* to be sure and get there. Didn't want a repeat of my first Minmus mission when I had to send up a little tanker to give the ship a shot of fuel to deorbit.