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

[NihilRex]

Has anyone tried to use this in any of the Linux Matlab replacements and gotten it to work?

[Arrowstar]

Has anyone tried to use this in any of the Linux Matlab replacements and gotten it to work?

It will not work. KSPTOT uses a compiled version of a Lambert solver for fast solver times. In addition, KSPTOT uses a number of MATLAB toolbox functions (from Optimization and Global Optimization) that simply don't exist in any MATLAB alternative.

Sorry.

[Drew Kerman]

Gaiiden: Any luck with trying out aerobraking code? I'm thinking I want to push out v1.1.9 this weekend if possible. No worries if not, I may just leave it until v1.1.10 then.

Nope, I'm still barely halfway through my Mun mission thanks to working through some game bugs/issues and also getting the hang of using MA in this capacity (going well on that front at least!). Falling under a month of lead-time for my scheduled tweets so I need to focus on getting through this mission and building back up my lead time before I can go off and experiment on stuff.

[Arrowstar]

Okay no worries. v1.1.9 will come this weekend then, and we'll work on aerobraking stuff as your time allows.

[Arrowstar]

Good news, all! I was able to get KSPTOT to run on MATLAB R2014b (minus some minor issues that need ironing out). I need to make sure it actually still compiles as a Windows application, but if it does, I think v1.2.0 will bring along an update from the old R2013a version I'm using now, and with that a move to the x64 architecture. Any objections?

[Drew Kerman]

Okay no worries. v1.1.9 will come this weekend then, and we'll work on aerobraking stuff as your time allows.

Yea, I'll just continue to give feedback on stuff I'm doing with the app - eventually I'll have an aerobraking scenario to play with. Given the way I'm playing, it would be good to actually be testing it in the game as an actual part of my playthrough.

Good news, all! I was able to get KSPTOT to run on MATLAB R2014b (minus some minor issues that need ironing out). I need to make sure it actually still compiles as a Windows application, but if it does, I think v1.2.0 will bring along an update from the old R2013a version I'm using now, and with that a move to the x64 architecture. Any objections?

Sounds good!

[Arrowstar]

I'm happy to announce the release of KSP TOT v1.1.9! This is a minor update release that adds some great new features to both Mission Architect and KSP TOT in general. Within Mission Architect, I'd like to particularly point your direction to the finite burn duration models and the new support for modeling FAR/NEAR aerobraking maneuvers. Also in MA are two new tools designed to help with other aspects of mission planning: a delta-v budget tool (lists out the delta-v required for each burn and sums them), and a launch window analysis tool that computes the idea launch time based on target orbit and launch site location.

IMPORTANT NOTE: This will likely be the final version of KSP TOT to use the R2013a version of the MATLAB Compiler Runtime. I intend to move over to MATLAB R2014b starting with KSP TOT v1.2.0. All KSP TOT users will need to download and install the new MCR before using v1.2.0. Install instructions will be updated in the OP to point to the new MCR.

• New Features for Mission Architect;
  
  • A new finite duration burn model that takes into account the duration of a burn, and thrust and Isp of the engine;
    
  • Aerobraking updated to include both stock and NEAR/FAR models;
    
  • A new launch window analysis tool;
    
  • A new delta-v budget tool;
    
  • Improvements to mission optimizer behavior;
    
  • Improvements to undo/redo functionality (was causing some slow-downs after many actions);
    
  • Bug fixes and other minor improvements;
    

  [*]Compiled KSPTOTConnect against KSP v0.90;

  [*]Added a search window length input to Rendezvous Maneuver Sequencer;

  [*]Some minor fixes to the KSPTOT Real Time System (RTS).

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

Edited January 24, 2015 by Arrowstar

[Drew Kerman]

I'd like to know more about the usage of the Launch Window tool. As in, what sort of ascent profile are you expecting when using it? Note I haven't played with it yet - maybe I'll understand it if/when I do? I will eventually, of course. But no launch for me for a couple of days or a week or more maybe.

Also, this has been bugging me for a while - not really sure exactly what the Equinoctial values are from the Graphical Analysis Tool. A cursory Google search did not turn up much in the way of any sort of basic explanation.

Delta-v budget tool is great, simple and effective.

[Arrowstar]

I'd like to know more about the usage of the Launch Window tool. As in, what sort of ascent profile are you expecting when using it? Note I haven't played with it yet - maybe I'll understand it if/when I do? I will eventually, of course. But no launch for me for a couple of days or a week or more maybe.

The launch windows shown are strictly when the orbital plane is overhead the launch site. I suspect you'll need to back off ascent_time/2 to get the actual launch time, but I really haven't tested it too much. In any event, no ascent profile assumed: you basically have to do that yourself.

Also, this has been bugging me for a while - not really sure exactly what the Equinoctial values are from the Graphical Analysis Tool. A cursory Google search did not turn up much in the way of any sort of basic explanation.

Equinoctial are also known as "non-singular elements." They're an element set that doesn't have a singularity when inclination and eccentricity go to zero. Basically, they're great for those circular, equatorial orbits (think geostationary orbits). I personally use them in place of eccentricity constraints: H1/K1 behave better that eccentricity when you use it in an optimizer setting.

I can get you a mathematical definition if you can't find one yourself. You'll see what I mean.

Delta-v budget tool is great, simple and effective.

Thanks!

---

In other news, I managed to get KSPTOT to compile against MATLAB R2014b. Anyone want to test it?

If you're interested, here are the instructions to get it installed:

1) Download v1.2.0 prerelease 0 (this is functionally equivalent to KSPTOT v1.1.9)

2) Download MCR R2014b x64 (the download page is here).

3) Install the MCR.

4) Unzip the KSP TOT package to some folder as per normal.

5) Run KSPTrajectoryOptimizationTool.exe

Some known issues at this point:

1) The GUI for the main application is a bit off yet. I am trying to figure out why there's a gap on the top of the GUI.

2) Some of the optimizer runs are seem a bit slower than normal, but still investigating.

3) The application is now purely a 64-bit application; people running 32-bit operating systems will not be able to run this.

I'd appreciate any feedback from those those who run the v1.2.0 version. Please let me know what you find.

[skykooler]

Who compiled the previous OSX version? Would they be able to compile the new version?

[Arrowstar]

Who compiled the previous OSX version? Would they be able to compile the new version?

That would be forum user "Bk2w", on his own initiative typically.

---

In other news, Gaiiden, I granted your wish, I believe:

TOD = transfer orbit duration

DV = Total Delta-v

You can try it out here (recall you'll need the updated 2014b MCR package installed first):

KSP TOT v1.2.0 Pre-release 1

Edited January 25, 2015 by Arrowstar

[immelman]

Hi immelman. Yes pretty much you are right, KSPTOT works with any star system but needs the bodies parameters, from a "bodies.ini" file it has in its root folder. The "bodies.ini" that comes with the standard KSPTOT distro is about the stock Kerbol system. For any other star system (including RSS) there is a nice utility from KSPTOT main menu/file/"Create New Bodies File From KSP". You must have KSPTOT Connect correctly installed within the KSP GameData folder, and have that KSP install running for that to work.

Copy the text from here and paste it into a file called bodiesRSS.ini or something:

http://pastebin.com/k9npkdKz

You can call it whatever you want, so long as it ends with *.ini.

Thank you for your help! Now let's see how close I can get to the mission profile

[Drew Kerman]

only gripes on 1.2 so far are minor. Can't seem to load mission files from the 32-bit version - I'm not sure if that's impossible though since the program doesn't throw an error it just fails to load it and the Open button stays greyed out and the mission file name is in the title bar but otherwise MA operates as normal.

Also weird rendering on the fonts and graphic displays - lines are thicker as if some extra AA is being applied to them. Not all fonts, just ones in message dialogs and in the graph windows.

Delta-v budget window considerations: it could be wider to accomodate longer event names. It fails to give a Dv amount for circularization burns. For now, work around is to select a circularize DV Maneuver and change it to a proscribed orbital vector maneuver which will show the actual Dv usage.

Edited January 25, 2015 by Gaiiden

[diomedea]

In other news, I managed to get KSPTOT to compile against MATLAB R2014b. Anyone want to test it?

Unlike all KSPTOT releases running on MCR 2013a (always requiring to be launched twice to run on my system), no prob starting KSPTOT 12.0 on MCR 2014b 64bit.

Once loaded, KSPTOT 12.0 has some weird RAM allocation. RAM effectively used (private bytes) is ~ 650KB, but RAM allocated to the program (virtual size) is > 4,600KB. Seems like MCR is enjoying too much the RAM available on a 64bit system .

Lines and coloured areas show much better on MCR 2014b (IMO). Could not see any issue with fonts, in any part of the UI, everything seems nice.

Tried some basic functionalities (porkchop plotting, multiple flyby, 2-burn maneuvers), all seems to work well and even somewhat faster (e.g., a simple Kerbin-Duna transfer porkchop takes ~11 sec. to complete calculations with KSPTOT 11.x; ~ 8 sec. with KSPTOT 12.0).

No issue with saving or loading mission files with MA. Of course had to give KSPTOT 12.0 rights to write and read files on my system, but then it worked like a charm.

[Arrowstar]

only gripes on 1.2 so far are minor. Can't seem to load mission files from the 32-bit version - I'm not sure if that's impossible though since the program doesn't throw an error it just fails to load it and the Open button stays greyed out and the mission file name is in the title bar but otherwise MA operates as normal.

Can you send me a copy of a mission file that doesn't load? I'll take a look. Also check the ksptot.log file that should be generated as you run KSPTOT for error messages.

Also weird rendering on the fonts and graphic displays - lines are thicker as if some extra AA is being applied to them. Not all fonts, just ones in message dialogs and in the graph windows.

Yes, MATLAB R2014b revamped the way lines and text are rendered (amongst many other things). Do they not look better? (They look much better on my system than R2013a.) Can I see a picture of what you're talking about?

Delta-v budget window considerations: it could be wider to accomodate longer event names. It fails to give a Dv amount for circularization burns. For now, work around is to select a circularize DV Maneuver and change it to a proscribed orbital vector maneuver which will show the actual Dv usage.

1) Will fix.

2) Will also fix.

Unlike all KSPTOT releases running on MCR 2013a (always requiring to be launched twice to run on my system), no prob starting KSPTOT 12.0 on MCR 2014b 64bit.

Awesome! I wonder if that issue was strictly with the MCR then.

Once loaded, KSPTOT 12.0 has some weird RAM allocation. RAM effectively used (private bytes) is ~ 650KB, but RAM allocated to the program (virtual size) is > 4,600KB. Seems like MCR is enjoying too much the RAM available on a 64bit system .

Could be. Interesting find.

Lines and coloured areas show much better on MCR 2014b (IMO). Could not see any issue with fonts, in any part of the UI, everything seems nice.

Tried some basic functionalities (porkchop plotting, multiple flyby, 2-burn maneuvers), all seems to work well and even somewhat faster (e.g., a simple Kerbin-Duna transfer porkchop takes ~11 sec. to complete calculations with KSPTOT 11.x; ~ 8 sec. with KSPTOT 12.0).

No issue with saving or loading mission files with MA. Of course had to give KSPTOT 12.0 rights to write and read files on my system, but then it worked like a charm.

This all sounds great! Thanks for the initial check out.

[Drew Kerman]

Unlike all KSPTOT releases running on MCR 2013a (always requiring to be launched twice to run on my system), no prob starting KSPTOT 12.0 on MCR 2014b 64bit.

I never had to start it twice but the x86 version does take a lot longer to load up than the x64 version.

Once loaded, KSPTOT 12.0 has some weird RAM allocation. RAM effectively used (private bytes) is ~ 650KB, but RAM allocated to the program (virtual size) is > 4,600KB. Seems like MCR is enjoying too much the RAM available on a 64bit system .

Same observation here, but no noticeable impact on my system overall

Lines and coloured areas show much better on MCR 2014b (IMO). Could not see any issue with fonts, in any part of the UI, everything seems nice.

I'm getting used to it now, the antialiasing of the fonts and graphs still annoys me a little bit but I guess that's just me being picky I like things crisp

No issue with saving or loading mission files with MA. Of course had to give KSPTOT 12.0 rights to write and read files on my system, but then it worked like a charm.

Just to be clear, you're loading mission files you created with the x86 version? Because otherwise yea .mat files load okay for me to, as long as they were saved with the x64 version

- - - Updated - - -

Can you send me a copy of a mission file that doesn't load? I'll take a look. Also check the ksptot.log file that should be generated as you run KSPTOT for error messages.

Any of the Mun III files I uploaded for you earlier. Here's the link again

Mission File

just tried and this is what's in my log:

        3003

Attempt to reference field of non-structure array.

Error in ma_updateMAData (line 24)



Error in ma_MainGUI>openMissionPlanMenu_Callback (line 536)



Error in ma_MainGUI>openMissionPlanToolbar_ClickedCallback (line 750)



Error in gui_mainfcn (line 95)



Error in ma_MainGUI (line 42)



Error in @(hObject,eventdata)ma_MainGUI('openMissionPlanToolbar_ClickedCallback',hObject,eventdata,guidata(hObject))


Error while evaluating PushTool ClickedCallback

Error writing to output stream.

Edit: another request I've been meaning to make for some time is making it so that you can't close the main KSPTOT window if any other windows are open, like RMS or MA.

Edited January 25, 2015 by Gaiiden

[Arrowstar]

Alright, this new pre-release addresses the two concerns with the Delta-v Budget window, as well as the issue with opening MA missions from v1.1.9. There's also a new KSPTOTConnect plugin that addresses a bug when attempting to pull spacecraft masses from KSP directly. In any event, please let me know how the new pre-release works.

KSP TOT v1.2.0 pre-release 2

Edit: another request I've been meaning to make for some time is making it so that you can't close the main KSPTOT window if any other windows are open, like RMS or MA.

Yeah, I've been meaning to do something like that for some time. I'll look at it tonight.

[Drew Kerman]

Alright, this new pre-release addresses the two concerns with the Delta-v Budget window, as well as the issue with opening MA missions from v1.1.9. There's also a new KSPTOTConnect plugin that addresses a bug when attempting to pull spacecraft masses from KSP directly. In any event, please let me know how the new pre-release works.

Nice. Totally missed the auto-mass feature. But why only through KSPTOTConnect? Did you see my post detailing what needs to be parsed from the SFS file to get the same thing?

Also, whats a good way to count number of orbits around a body? If that's not something that could be added to the graphical analysis window, should I just plot my trajectory and count the number of times my true anomaly passes zero?

And a suggestion that I think you should only consider if others would find this useful too - being able to multi-select SFS files and tell MA to load the orbit of 1 ship across time. So, I create a save file after every orbital maneuver I do in the game in order to rebuild the trajectories in MA and plot stuff from it. Currently I have to load the orbit from each SFS file individually into an event state, then go back and insert Coast events inbetween by copying out the UT of the next event.

Edited January 25, 2015 by Gaiiden

[Arrowstar]

Nice. Totally missed the auto-mass feature. But why only through KSPTOTConnect? Did you see my post detailing what needs to be parsed from the SFS file to get the same thing?

I saw it. Maybe I'm not the greatest at parsing text files, but for the life of me, I cannot figure out how to parse the SFS format to get masses. The orbit is really easy: there's only one orbit per vessel. Here, though, there are multiple parts per vessel and that adds some challenge. If anyone has any suggestions on turning the SFS file into a data structure of some kind, I'd definitely take them. I'm stumped...

Also, whats a good way to count number of orbits around a body? If that's not something that could be added to the graphical analysis window, should I just plot my trajectory and count the number of times my true anomaly passes zero?

Yeah, just count periapsis crossings. That's the easiest way.

And a suggestion that I think you should only consider if others would find this useful too - being able to multi-select SFS files and tell MA to load the orbit of 1 ship across time. So, I create a save file after every orbital maneuver I do in the game in order to rebuild the trajectories in MA and plot stuff from it. Currently I have to load the orbit from each SFS file individually into an event state, then go back and insert Coast events inbetween by copying out the UT of the next event.

http://i.imgur.com/a2xSzmB.png

Since I suspect you're the only use case for this, I think we'll leave it for now and others can chime in if they think if might be useful.

[Drew Kerman]

I saw it. Maybe I'm not the greatest at parsing text files, but for the life of me, I cannot figure out how to parse the SFS format to get masses.

What language are you coding in?

Since I suspect you're the only use case for this, I think we'll leave it for now and others can chime in if they think if might be useful.

We are in agreement then, cool.

[Arrowstar]

What language are you coding in?

MATLAB, of course.

[Drew Kerman]

MATLAB, of course.

... oh, I thought MATLAB was a library you linked to C++ or C# or something like that. I guess then MATLAB just doesn't have a robust means of parsing text. Back when I was programming games I was parsing many a custom level or config file format in C++ with no problems, similar in a lot of ways to how SFS files are laid out.

Also, forgot to post this from my error log earlier this evening. MA stopped letting me import DV Maneuvers. I can't recall exactly what I was doing before the issue arose, sorry.

                                            First-order      Norm of
 Iter F-count            f(x)  Feasibility   optimality         step
    0       5    1.000000e+00    6.552e-03    0.000e+00
    1      10    1.000000e+00    4.069e-05    0.000e+00    9.005e-02
    2      16    1.000000e+00    2.045e-05    0.000e+00    3.315e-02
    3      22    1.000000e+00    1.028e-05    0.000e+00    6.210e-02
    4      28    1.000000e+00    5.159e-06    0.000e+00    1.143e-01
    5      34    1.000000e+00    2.593e-06    0.000e+00    2.063e-01
    6      40    1.000000e+00    1.320e-06    0.000e+00    3.542e-01
    7      46    1.000000e+00    6.683e-07    0.000e+00    1.083e-01

Local minimum found that satisfies the constraints.

Optimization completed because the objective function is non-decreasing in 
feasible directions, to within the default value of the function tolerance,
and constraints are satisfied to within the default value of the constraint tolerance.



Error using reshape
To RESHAPE the number of elements must not change.

Error in getNTWdvVect (line 5)



Error in ma_MainGUI>uploadSelectedDVManuever (line 1143)



Error in ma_MainGUI>uploadDVManeuverContextMenu_Callback (line 1125)



Error in gui_mainfcn (line 95)



Error in ma_MainGUI (line 42)



Error in @(hObject,eventdata)ma_MainGUI('uploadDVManeuverContextMenu_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating Menu Callback

Error writing to output stream.

Error using reshape
To RESHAPE the number of elements must not change.

Error in getNTWdvVect (line 5)



Error in ma_MainGUI>uploadSelectedDVManuever (line 1143)



Error in ma_MainGUI>uploadDVManeuverContextMenu_Callback (line 1125)



Error in gui_mainfcn (line 95)



Error in ma_MainGUI (line 42)



Error in @(hObject,eventdata)ma_MainGUI('uploadDVManeuverContextMenu_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating Menu Callback

Error writing to output stream.

Error using reshape
To RESHAPE the number of elements must not change.

Error in getNTWdvVect (line 5)



Error in ma_MainGUI>uploadSelectedDVManuever (line 1143)



Error in ma_MainGUI>uploadDVManeuverContextMenu_Callback (line 1125)



Error in gui_mainfcn (line 95)



Error in ma_MainGUI (line 42)



Error in @(hObject,eventdata)ma_MainGUI('uploadDVManeuverContextMenu_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating Menu Callback

Error writing to output stream.

Error using reshape
To RESHAPE the number of elements must not change.

Error in getNTWdvVect (line 5)



Error in ma_MainGUI>uploadSelectedDVManuever (line 1143)



Error in ma_MainGUI>uploadDVManeuverContextMenu_Callback (line 1125)



Error in gui_mainfcn (line 95)



Error in ma_MainGUI (line 42)



Error in @(hObject,eventdata)ma_MainGUI('uploadDVManeuverContextMenu_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating Menu Callback

Error writing to output stream.

[Arrowstar]

Hmm, interesting. Can you reproduce it? This one is going to be hard without a test I can work with.

[hab136]

Okay, I think I know what you're asking. You want to be able to plan N finite maneuvers based on the results of one (probably impulsive) maneuver such that the N finite maneuvers achieve the same result of the one (probably impulsive) maneuver?

That sounds exactly what I asked for before. Replace one 800 m/s burn at periapsis with two 400 m/s burns at periapsis, for example.

Is the problem that it's hard to find a general-purpose solver? Would it be simpler if the maneuver splitter only worked on specific types of maneuvers? For example transfer burns, like the burn to go from Kerbin orbit to Duna?

If that's the case... boy, that's hard. Honestly, the only way Mission Architect could pull that off is to do exactly what you'll have to do already, namely, optimize the nine burns together. In short, there's no good way apparent to me at the moment to automate this.

Here's what I'd recommend doing: instead of trying to optimize the burns all together, just optimize them in sets. Say you know it'll take ~2000 m/s to leave Kerbin and get to where you're going. Your first 2 burns can do, say, 800 m/s total (maybe 400 m/s each). Your next two burns can 600 total (say 300 m/s each). Your next two burns can do 400 m/s (200 m/s each). Your last three burns can then take up the last 200 m/s in whatever way works.

Best way to do this is to only optimize one or two of the burn unit vectors (prograde and normal, probably) and leave the remaining at 0.0. Then just optimize in stages, attempting to maximize distance to Kerbin at apoapsis.

I'm not following... how do I calculate those 9 burns in the first place?

For a simpler case of just splitting a transfer burn in half, could I just calculate a 800 m/s transfer burn using the transfer planner, then change it to a 400 m/s burn, then insert a 400 m/s burn an orbit before at the same position, and then hit optimize?

[Arrowstar]

Okay, so I have some thoughts on how something like this could work. It would not be general, though. It would require that all intermediate orbits are not hyperbolic and only work with impulsive maneuvers. There would also probably be a maximum number of burns you could create from one burn (~10 or so).

I'll have more details when I get) home from work. Sound okay in the mean time?