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

[gruneisen]

On 8/3/2016 at 8:33 PM, blu3wolf said:

Arrowstar, just a heads up that TOT is awesome, in case you didnt know.

That is all.

In fact it is! I'm beginning to think this may finally kick me back over to windows to run KSP since we now have working 64-bit.

Perhaps @salajander could chime in? He seems to have gotten this running not too long ago...I wonder if he could provide the wineHQ-staging version he was running for comparison?

Also, if this is going to devolve into a conversation about supporting Linux for a mod which definitely does not, do we need to take this somewhere else?

Thanks and cheers!

Edited August 5, 2016 by gruneisen

[ruiluth]

23 hours ago, gruneisen said:

if this is going to devolve into a conversation about supporting Linux for a mod which definitely does not

Nah, I was just hoping it would be as easy as changing a font. I don't think it will be, since I've realized that what it's doing is vertically flipping the entire porkchop plot area. When I take a screenshot and mirror it vertically I can read it fine. That seems like a reasonably good workaround to me, just taking screenshots and mirroring them with GIMP. Makes it readable with not too much effort

[Arrowstar]

On 8/3/2016 at 10:33 PM, blu3wolf said:

Arrowstar, just a heads up that TOT is awesome, in case you didnt know.

That is all.

Thanks! :-) 

[salajander]

On 8/4/2016 at 1:50 AM, gruneisen said:

In fact it is! I'm beginning to think this may finally kick me back over to windows to run KSP since we now have working 64-bit.

Perhaps @salajander could chime in? He seems to have gotten this running not too long ago...I wonder if he could provide the wineHQ-staging version he was running for comparison?

Also, if this is going to devolve into a conversation about supporting Linux for a mod which definitely does not, do we need to take this somewhere else?

Thanks and cheers!

Running it in WINE stopped working for me with the move to the most recent MATLAB runtime.

I filed https://bugs.winehq.org/show_bug.cgi?id=40781 about the URI bug, but no one has looked into it, and it's beyond my ken to figure out.

I've since bit the bullet and set up a Windows 10 VM just to run KSP TOT....

Edited August 6, 2016 by salajander

[antilochus]

Another RSS user here. Using prerelease 9. I've got a probe in coplanar orbit with the Moon that I use to roughly plan out future interplanetary missions. I'm getting a bit of an odd result using MFMS (pulling initial orbital elements from active vessel) for a simple Earth->Venus transfer.

Maneuver delta-v of 9.885km/s largely from huge normal component compares to mechjeb planner generating 3.623km/s departure burn. Happy to share whatever details would be helpful.

Edit: I've confirmed that the basic KSPTOT porkchop generates a similar departure burn:

Burn Information to Depart Earth
---------------------------------------------
Total Delta-V =              8.00535 km/s
Prograde Delta-V =           733.11198 m/s
Orbit Normal Delta-V =       7971.70638 m/s
Radial Delta-V =             -0.46899 m/s
---------------------
Burn True Anomaly =          16.65828 deg
Burn Time Past Peri. =       250.84946 sec
Burn Time Before Peri. =     5172.29241 sec
Initial Orbit Period =       5423.14187 sec

Edit 2: on further reflection (shower thoughts), I suspect this is a quirk of MFMS... while I didn't load it into KSP, I think this burn was trying to match Venus plane. I've never done anything in MA before but if I can figure it out tonight I'll set up a parking orbit that matches the hyperbolic escape and optimize from there.

Edit 3: After going back through and reading the earlier issues with RSS, I'll first confirm that the starting orientation of the planets looks right... wondering if the negative starting epoch in RSS is being reflected accurately in KSPTOT.

Edited August 9, 2016 by antilochus

[Arrowstar]

17 hours ago, antilochus said:

Another RSS user here. Using prerelease 9. I've got a probe in coplanar orbit with the Moon that I use to roughly plan out future interplanetary missions. I'm getting a bit of an odd result using MFMS (pulling initial orbital elements from active vessel) for a simple Earth->Venus transfer.

Maneuver delta-v of 9.885km/s largely from huge normal component compares to mechjeb planner generating 3.623km/s departure burn. Happy to share whatever details would be helpful.

Edit: I've confirmed that the basic KSPTOT porkchop generates a similar departure burn:

Burn Information to Depart Earth
---------------------------------------------
Total Delta-V =              8.00535 km/s
Prograde Delta-V =           733.11198 m/s
Orbit Normal Delta-V =       7971.70638 m/s
Radial Delta-V =             -0.46899 m/s
---------------------
Burn True Anomaly =          16.65828 deg
Burn Time Past Peri. =       250.84946 sec
Burn Time Before Peri. =     5172.29241 sec
Initial Orbit Period =       5423.14187 sec

Edit 2: on further reflection (shower thoughts), I suspect this is a quirk of MFMS... while I didn't load it into KSP, I think this burn was trying to match Venus plane. I've never done anything in MA before but if I can figure it out tonight I'll set up a parking orbit that matches the hyperbolic escape and optimize from there.

Edit 3: After going back through and reading the earlier issues with RSS, I'll first confirm that the starting orientation of the planets looks right... wondering if the negative starting epoch in RSS is being reflected accurately in KSPTOT.

I can certainly try to help.  Can I get the bodies.ini file you're using for RSS?  Can I also get some screenshots that show how you have things set up?

Thanks!

 

EDIT: Just a heads up, the issue you're running into is probably that your initial orbit plane (inclination and RAAN values) are not in line with the departure orbit.  If you try to adjust those you should be able to get your orbital normal delta-v down to zero.

Edited August 9, 2016 by Arrowstar

[antilochus]

50 minutes ago, Arrowstar said:

Just a heads up, the issue you're running into is probably that your initial orbit plane (inclination and RAAN values) are not in line with the departure orbit.  If you try to adjust those you should be able to get your orbital normal delta-v down to zero.

Thanks! Yeah... that's what I was trying to say with "match Venus plane"... match the departure plane. I was even picturing this image from a textbook I flip through on the subway!

Just to improve my understanding, tell me if I'm off on this:

Both the MFMS and transfer porkchop solve for a departure orbit that is independent of the initial orbit plane -- so when MFMS generate the maneuvers, or the porkchop 'compute departure burn' is selected, the resulting burn could very well include a very large plane change. As a result, once I calculate the departure orbit with generic orbital elements (say a basic 28.6 cape 90 azimuth), I should go back into the 'current orbit' and input the same values from the departure hyperbola so as to reduce normal dV to zero.

 

[Arrowstar]

3 minutes ago, antilochus said:

Both the MFMS and transfer porkchop solve for a departure orbit that is independent of the initial orbit plane -- so when MFMS generate the maneuvers, or the porkchop 'compute departure burn' is selected, the resulting burn could very well include a very large plane change. As a result, once I calculate the departure orbit with generic orbital elements (say a basic 28.6 cape 90 azimuth), I should go back into the 'current orbit' and input the same values from the departure hyperbola so as to reduce normal dV to zero.

Yes!  That is precisely correct!

[antilochus]

Nice.^{armchair rocket science victory!!}

In feeding back the outbound orbit values into initial state for MFMS E-V-M trajectory I was definitely successful in reducing total delta-v and the normal component of the departure burn (from the lunar target probe's orbit as a placeholder).

Result 1 - 10km/s burn at E/V

Result 2 (using outbound values from 1) - 4.7km/s burn at E, flyby V... nice!

Result 3 (using outbound values from 2) - less nice

I iterated there a few times without improvement. I guess some of this could be attributable to the genetic algorithm, but I have the sense MFMS is probably much more reliably used standalone (without MA) in stock KSP where the initial orbit precision is less critical? Should I not expect zero normal, or should I just be using MA instead of MFMS here?

[Arrowstar]

1 minute ago, antilochus said:

I iterated there a few times without improvement. I guess some of this could be attributable to the genetic algorithm, but I have the sense MFMS is probably much more reliably used standalone (without MA) in stock KSP where the initial orbit precision is less critical? Should I not expect zero normal, or should I just be using MA instead of MFMS here?

So the reason that you had "less nice" results in result 3 is because you found a different gravity assist window.  The inclination and RAAN of the orbit are more or less unique to each launch window.  So what I would try to do is to limit the launch window on the second run (your Result 3 attempt) to tightly bound the Result 2 launch window (the departure date).  That should improve things.

Moving along: actually, MFMS is better used as an input into MA, but it can be used stand-alone as well (though with less precise results, of course).  You can get a near-zero normal component of your departure burn, but it may take some trial and error to achieve. 

[antilochus]

Yeah, as soon as I pressed submit I started fiddling with the window constraint. Thanks for your help and amazing piece of work here. Hopefully will report back with some great results in next few days!

[Arrowstar]

1 minute ago, antilochus said:

Yeah, as soon as I pressed submit I started fiddling with the window constraint. Thanks for your help and amazing piece of work here. Hopefully will report back with some great results in next few days!

Perfect, have fun!

[antilochus]

On 8/9/2016 at 8:40 PM, Arrowstar said:

Perfect, have fun!

This is incredible. Just spent way too long tonight working on a Mercury mission in MA. It's not cheap, but I'm launching on my F9 FT clone, not a Delta II like MESSENGER. I'll share some pics when I fly it (not for a few years, so might take a while).

I noticed MFMS doesn't like revisiting the target planet like MESSENGER or Mariner did. Any tips? I'm thinking MA optimizer could probably handle this if I play around with it.

EVEEJ seems to work just fine*, that should be fun...

Edit: although MFMS doesn't provide for what I keep seeing referred to as "DSM", so I guess it might miss out on some more efficient trajectories. I feel like I could probably make it work with MA, but would take some tinkering.

Edited August 11, 2016 by antilochus

[Ruedii]

On 6/18/2013 at 0:59 AM, Arrowstar said:

Running on Linux

 

It has been suggested that it is possible to run the Windows version of KSPTOT on Linux using WINE.  Here are the steps.  I have not tried them personally, so you follow them at your own risk.

The WINE internal version of VC Runtime should be sufficient in newer versions of Wine.  You should only have to install the Matlab runtime now.

Of course, there is only one way to know for sure . . .  (So, if it doesn't work and reports stubs to the log install VC Runtime.)

 

Edited August 16, 2016 by Ruedii
Moar Details.

[Arrowstar]

On 8/10/2016 at 11:39 PM, antilochus said:

Edit: although MFMS doesn't provide for what I keep seeing referred to as "DSM", so I guess it might miss out on some more efficient trajectories. I feel like I could probably make it work with MA, but would take some tinkering.

Correct, it only does maneuvers at departure and flyby periapsis.  Too many variables to optimize otherwise.

[officialmugi]

I can't seem to be able to generate a bodies.ini file for my RSS playthrough. It cannot seem to be able to connect to the plugin, which I have installed properly in the GameData folder. I am in the flight scene and it still says that it cannot connect to the plugin, even when I disable my firewall.

[Arrowstar]

On 8/15/2016 at 8:33 AM, officialmugi said:

I can't seem to be able to generate a bodies.ini file for my RSS playthrough. It cannot seem to be able to connect to the plugin, which I have installed properly in the GameData folder. I am in the flight scene and it still says that it cannot connect to the plugin, even when I disable my firewall.

Can I get a copy of the ksptot.log file and can you check to see if there are any relevant messages in the KSP debug log window?

[Arrowstar]

Hi everyone,

I'm happy to announce the release of KSP Trajectory Optimization Tool v1.5.5!  As usual, the download is in the OP.  This version includes quite a few quality of life improvements.  The change log is as follows:

• Fixed issue with starting parallel pool in Mission Architect (matlabpool -> parpool)
• Added ability to remove mass at a constant rate from spacecraft during coasts
• Added ability to rename propellant types
• Mass dump GUI now shows fuel type being dumped for delta-v dump
• DV maneuvers now have a line color for plotting similar to coasts
• Added ability to run multiple MFMS runs in sequence in a hands-off manner
• Added ability to save the text output from MFMS runs to file without manual copy/paste
• Added function to Mission Architect to create a "trajectory map" similar to what MFMS outputs (Tools -> Create Trajectory Map)
• Replaced the previous end-of-optimization prompt with a scorecard that allows the user to choose between the final optimization result, the optimization iteration with the best objective function value, or the optimization iteration with the best constraint value.
• Added "Copy Orbit After Selected Event" item to MA script context menu
• Lists of celestrial bodies which contain the full body list are now arranged in a hierarchical order with appropriate indenting
• Fixed bug with MFMS in which the waypoint panel header did not update when the central body is changed
• Fixed bug with other spacecraft and ground targets related to their body.  May need to recreate these items if you're on a v1.5.5 pre-release.
• Added initial orbit epoch and mean anomaly to the Multi-Flyby Maneuver Sequencer input
• Fixed a bug with the algorithm that adjusts departure time to account for mean anomaly and epoch in the "Compute Departure" tool.
• Fixed a bug with MFMS "Get Orbit from SFS File" functionality

Please let me know if you have any questions.  Thanks!

[Drew Kerman]

I saw the huge change list and was like awwwwwwwwws yeeeaaa then started reading it and was like wait a min.... Hahah I forgot all the recent changes were preview builds  still, yay for official release! 

[Arrowstar]

34 minutes ago, Drew Kerman said:

I saw the huge change list and was like awwwwwwwwws yeeeaaa then started reading it and was like wait a min.... Hahah I forgot all the recent changes were preview builds  still, yay for official release! 

Haha sorry!  I put out the previews so people can play with the latest and greatest if they want and also help find bugs. Since I haven't found any recent bugs myself, and I haven't heard mention of any from others in some time, I figured I could go ahead and release yesterday, so I did. :-) 

[DivisionByZero]

I was away from my computer for a while but now I'm back.  I had some suggested features for you to add after working on a mission for Duna.

The Split-maneuver tool in Mission Architect could use some love.  One feature that might be cool is to have an "equal time" option.  Because of propellant usage on previous burns, the same delta-V can be obtained with a shorter burn.  In the standard, identical splitting, this means later burns require less clock time.  There is already the manual method for redistribution, but having an automatic calculation to this effect could be helpful.  

At least in 1.5.4, the splitting tool did not adjust the burn time to account for new orbital periods added as a result of multiple burns.  For large numbers of extra burns, there are a number of added orbits before actually leaving the original central body.  As a result, previous calculations for things like true anomaly at burn from the porkchop plot tool need to be re-optimized.  Alternatively, for the given delta-V splitting, the "added" orbit time can be added in but the initial burn time moved to an earlier UT to retain the original exit information.  I had to do this manually just now with a dummy splitting "wait" period that was deleted after I split-up the maneuver.

There might be some others, but I'll have to remember them later.

[Arrowstar]

19 hours ago, DivisionByZero said:

The Split-maneuver tool in Mission Architect could use some love.  One feature that might be cool is to have an "equal time" option.  Because of propellant usage on previous burns, the same delta-V can be obtained with a shorter burn.  In the standard, identical splitting, this means later burns require less clock time.  There is already the manual method for redistribution, but having an automatic calculation to this effect could be helpful.  

This is a good suggestion.  I can make the percentages impact either the fraction of delta-v or fraction of burn time on each burn.

Quote

At least in 1.5.4, the splitting tool did not adjust the burn time to account for new orbital periods added as a result of multiple burns.  For large numbers of extra burns, there are a number of added orbits before actually leaving the original central body.  As a result, previous calculations for things like true anomaly at burn from the porkchop plot tool need to be re-optimized.  Alternatively, for the given delta-V splitting, the "added" orbit time can be added in but the initial burn time moved to an earlier UT to retain the original exit information.  I had to do this manually just now with a dummy splitting "wait" period that was deleted after I split-up the maneuver.

So I'm not sure what you're getting at here?  You want MA to split the maneuver and somehow account for the longer coast time around your starting body in a calculation done in MFMS or something like that?  I don't see how it could as MA has no knowledge of anything that's going on in MFMS or anything else...

-------------------------------------

EDIT:

Something like this perhaps?

Edited August 20, 2016 by Arrowstar

[DivisionByZero]

5 hours ago, Arrowstar said:

So I'm not sure what you're getting at here?  You want MA to split the maneuver and somehow account for the longer coast time around your starting body in a calculation done in MFMS or something like that?  I don't see how it could as MA has no knowledge of anything that's going on in MFMS or anything else...

Example: I use the opening tool - porkchop plotter thingy -  to calculate the most efficient burn to Duna.  This burn has a specific departure date and angle associated with it for peak efficiency.  I put this info into mission architect and re-optimize the burn so it actually hits the target SOI.  If I then ask it to split the maneuver into 6, say, burns, then there are now 5 more orbits of increasing length.  Now, however, the actual time of departure (i.e. when a hyperbolic orbit is achieved on the final burn) is on the 6th orbit which is potentially days after the originally calculated.  Now, my departure date is not as efficient as it could be.

Consider instead, what I did on my last mission plan: I got a departure for Duna at optimal time.  On a previous MA run, I took this and split the maneuver into 6 burns and then manually calculated the increment in time needed.  I then made a new MA run, but this time, I added a dummy coast step that added the exact change in UT to compensate the 6 burn split I planned ahead.  I then kept this in, input the optimum burn and re-optimized to actually hit Duna.  I then split the maneuver and deleted the dummy coast step.  Now I was departing Kerbin much closer to the optimum time for departure and re-optimizing the final delta-V maneuver required very little change.

What I'm suggesting is that you put some option in to do all that calculation and change the initial UT to a lower value if the user wants because I had to keep track of a bunch of stuff to do what I did.  Maybe I'm just slow on some option you already have, but it came to mind.

 

Also: the option to split on time and your UI look great!  

[Arrowstar]

11 hours ago, DivisionByZero said:

Example: I use the opening tool - porkchop plotter thingy -  to calculate the most efficient burn to Duna.  This burn has a specific departure date and angle associated with it for peak efficiency.  I put this info into mission architect and re-optimize the burn so it actually hits the target SOI.  If I then ask it to split the maneuver into 6, say, burns, then there are now 5 more orbits of increasing length.  Now, however, the actual time of departure (i.e. when a hyperbolic orbit is achieved on the final burn) is on the 6th orbit which is potentially days after the originally calculated.  Now, my departure date is not as efficient as it could be.

Consider instead, what I did on my last mission plan: I got a departure for Duna at optimal time.  On a previous MA run, I took this and split the maneuver into 6 burns and then manually calculated the increment in time needed.  I then made a new MA run, but this time, I added a dummy coast step that added the exact change in UT to compensate the 6 burn split I planned ahead.  I then kept this in, input the optimum burn and re-optimized to actually hit Duna.  I then split the maneuver and deleted the dummy coast step.  Now I was departing Kerbin much closer to the optimum time for departure and re-optimizing the final delta-V maneuver required very little change.

What I'm suggesting is that you put some option in to do all that calculation and change the initial UT to a lower value if the user wants because I had to keep track of a bunch of stuff to do what I did.  Maybe I'm just slow on some option you already have, but it came to mind.

I feel like you may be making it too complicated on yourself.  Maybe try something like this?

1. Run your normal Kerbin-Duna plan in the porkchop plotter.  Get the optimal departure and arrival dates.
2. Set up your Mission Architect plan as normal with one burn.  Achieve a successful Duna trajectory.
3. Split the burn into N burns.
4. Right click on the first burn and select "Copy UT at End of Selected Event."  Save this time.
5. Right click on the last burn and select "Copy UT at End of Selected Event."  Save this time.
6. Subtract the smaller time from the larger time to get the delta-time between the burns.
7. Subtract this delta-time from the initial orbit epoch.
8. Re-optimize the trajectory, optimizing at least the last burn and preceeding coast true anomaly, but possibility also some intermediate burns.  Make sure to optimize the true anomaly of the coast immediately prior to any burn you do optimize.
9. ???
10. Profit?

What do you think?  This seems fairly straightforward and easy to do to me, but I haven't tried it out.  It's purely hypothetical at this point.

[DivisionByZero]

10 hours ago, Arrowstar said:

I feel like you may be making it too complicated on yourself.  Maybe try something like this?

1. Run your normal Kerbin-Duna plan in the porkchop plotter.  Get the optimal departure and arrival dates.
2. Set up your Mission Architect plan as normal with one burn.  Achieve a successful Duna trajectory.
3. Split the burn into N burns.
4. Right click on the first burn and select "Copy UT at End of Selected Event."  Save this time.
5. Right click on the last burn and select "Copy UT at End of Selected Event."  Save this time.
6. Subtract the smaller time from the larger time to get the delta-time between the burns.
7. Subtract this delta-time from the initial orbit epoch.
8. Re-optimize the trajectory, optimizing at least the last burn and preceeding coast true anomaly, but possibility also some intermediate burns.  Make sure to optimize the true anomaly of the coast immediately prior to any burn you do optimize.
9. ???
10. Profit?

What do you think?  This seems fairly straightforward and easy to do to me, but I haven't tried it out.  It's purely hypothetical at this point.

That's basically the process.  I used the fictitious UT and dummy setup because I was making sure I could make the launch window which was tight, but this is it.  It would be a nifty feature for folks who want to/have to split a burn a whole bunch.  I had six burns because I was moving 140 t on a single poodle and needed 1000 m/s total.  It adds up as more and more orbits go out even past Mun.