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

[Arrowstar]

And here's the pre-release, version 3 with debugging:

KSPTOT V0.11 PRE-RELEASE 3

Please give this a try and tell me what happens. Note: you need to FULLY remove the KSPTOTConnect folder from your GameData folder and replace it with the one in the ZIP file.

See the above few posts of mine for the change log.

I'd appreciate feedback from those of you who use it. This is my "release candidate" version, so if no one has problems with it, I'll release it at v0.11. Please let me know!

Here's a teaser for your viewing pleasure...

[Arrowstar]

Arrow,

I used R2013a running on OSX 10.8.5. 'deploytool' targeting a Standalone Application with projectMain.m as the Main File, everything in src/ as Shared Resources. The biggest hurdle is that the Lambert Arc solver (lambert.mexw32) you have in the source directories was compiled for Win32, and not usable on a Mac. I kept running into problems where Matlab would tap the Map Toolbox instead, getting very confused. I grabbed what I believe is the same source code (http://www.mathworks.com/matlabcentral/fileexchange/26348-robust-solver-for-lamberts-orbital-boundary-value-problem) and compiled it into a lambert.mexmaci64 that seems to work with TOT. End result is a script and executable that sure looks like KPSTOT on Windows. The script is needed to set environment variables that point to MCR, which is a bit awkward, but all the functionality of the tool seems to be working as I'd expect.

I'm happy to help out with testing as my time allows. I'm a software/hardware engineer by training and I've used Matlab quite a bit through work for modeling and exploring demodulation schemes, error correcting codes, and DSP chains. Don't have much background with orbital mechanics, sadly, but KSP is so much fun that it's making me learn like crazy.

-Brian

Got it. Nice investigation work to get it all working! Once v0.11 is released, I'll let you create your package and I'll throw it up on the forum thread. I'm going to call it somewhat unsupported, but it should work out alright based on your assessment of version v0.10.

Thanks.

[draeath]

"Get Orbit from SFS File" doesn't seem to be working for me, at least on the "Enter Transfer & Orbit Information" dialog after choosing "Compute Departure Burn."

I browse to and select my persistent.sfs, and nothing happens - all the values remain zero and I'm not prompted for anything further etc. Here's a video capture of what is going on. I have around 10 active flights in this persistence file.

EDIT: this is 0.10 btw, have not had a chance to try your "RC" there, yet

EDIT2: I'd like to request the ability to define ranges (peferably CIDR ranges) in IPAddressWhitelist.txt

Edited January 8, 2014 by draeath

[Arrowstar]

"Get Orbit from SFS File" doesn't seem to be working for me, at least on the "Enter Transfer & Orbit Information" dialog after choosing "Compute Departure Burn."

I browse to and select my persistent.sfs, and nothing happens - all the values remain zero and I'm not prompted for anything further etc. Here's a video capture of what is going on. I have around 10 active flights in this persistence file.

EDIT: this is 0.10 btw, have not had a chance to try your "RC" there, yet

EDIT2: I'd like to request the ability to define ranges (peferably CIDR ranges) in IPAddressWhitelist.txt

1) Thanks for the bug report, I'll fix it this weekend.

2) I'll look into defining ranges. I'm pretty much learning this stuff from scratch, so it make take some research.

These two features should be done by the end of this weekend. I'm going to compile the official 0.11 release before Sunday evening and call it good to go. Hurrah!

EDIT: (1) was easy enough to fix. They changed "OBJ" to "REF" in the orbit definition in the SFS file and didn't tell anyone. D'oh!

Edited January 11, 2014 by Arrowstar

[Arrowstar]

I'm pleased to announce the release of KSP Trajectory Optimization Tool v0.11! This is a major release that includes the following:

• New application: KSPTOT Mission Control Center. Connects to KSPTOT using the new KSPTOT Connect plugin (see below). Offers users on different PCs the ability to act as mission controllers by providing console screens with subsystem data on them.
  
  • Console pages available in the MCC:
    
    • Orbital Operations
      
    • ACS/Dynamics (attitude control and pointing)
      
    • Power/Thermal
      
    • Propulsion
      
    • Telemetry Monitor
      

  [*]New plugin: KSPTOT Connect. Allows users to connect KSPTOT to KSP (running on the same PC) to perform various tasks:

  • Grab the orbit and game UT from straight from KSP!
    
  • Upload maneuver nodes from the various applications!
    
  • Place in your GameData directory in your KSP directory.
    

  [*]A handful of minor fixes on the KSP TOT side.

  • Importing orbits from SFS now works for 0.23.
    
  • Some other fixes.
    

See the OP for download details and some new images! Bug reports and comments are welcome, please post them here.

Enjoy!

[Galane]

I'm pleased to announce the release of KSP Trajectory Optimization Tool v0.11! This is a major release that includes the following:

[*]New application: KSPTOT Mission Control Center. Connects to KSPTOT using the new KSPTOT Connect plugin (see below). Offers users on different PCs the ability to act as mission controllers by providing console screens with subsystem data on them.

Enjoy!

[mic_e]

Arrowstar, would you mind allowing tavert to create Linux binaries for KSPTOT despite the non-derivative part of the license?

I'd like to test this awesome tool, but don't have any Windows available.

[ormi]

Hello,

I encountered a bug on win8 x64 with the version 0.11. First time I try this tool, so I don't know if it was working in an older version.

Here are the steps I use to reproduce the problem :

1. Open KSPTOT
   
2. Departure Kerbin
   
3. Get UT by KSP (2075910.59 or anything more than 20 days)
   
4. Arrival Moho
   
5. Let 0 (or anything below 29 days)
   
6. Compute Porkchop Plot
   

Result :

It seems to want me to travel back in the past

With an Earliest Arrival Time at 28 days :

29 days :

30 days :

-->LogFile<--

Also, the tooltip is under the scale on the right :

[MaverickSawyer]

I am unable to get any response from KSP TOT. It shows up in my processes, but it never starts. I do have Avast, but it's not putting up any alarms, so I'm not quite sure what's going on.

EDIT: Scratch that, it's working fine after I updated Avast. :/

Edited January 12, 2014 by MaverickSawyer

[Arrowstar]

Arrowstar, would you mind allowing tavert to create Linux binaries for KSPTOT despite the non-derivative part of the license?

I'd like to test this awesome tool, but don't have any Windows available.

Tavert, if you want to do this, shoot me a PM and I'll give you permission and some basic instructions.

I am unable to get any response from KSP TOT. It shows up in my processes, but it never starts. I do have Avast, but it's not putting up any alarms, so I'm not quite sure what's going on.

EDIT: Scratch that, it's working fine after I updated Avast. :/

Good to know!

[Arrowstar]

Hello,

I encountered a bug on win8 x64 with the version 0.11. First time I try this tool, so I don't know if it was working in an older version.

Here are the steps I use to reproduce the problem :

1. Open KSPTOT
   
2. Departure Kerbin
   
3. Get UT by KSP (2075910.59 or anything more than 20 days)
   
4. Arrival Moho
   
5. Let 0 (or anything below 29 days)
   
6. Compute Porkchop Plot
   

Result :

It seems to want me to travel back in the past

http://tama-k.brikabrok.net/ksp/bug1.png

With an Earliest Arrival Time at 28 days :

http://tama-k.brikabrok.net/ksp/bug2.png

29 days :

http://tama-k.brikabrok.net/ksp/bug3.png

30 days :

http://tama-k.brikabrok.net/ksp/bug4.png

-->LogFile<--

Also, the tooltip is under the scale on the right :

http://tama-k.brikabrok.net/ksp/bug5.png

Hi! Your problem is that no point in the porkchop plot is simultaneously A) less than the maximum delta-v in the options menu (Edit -> Options -> Max. Delta-V to Plot) and has an arrival date greater than its departure date (which is obviously necessary). Do not use a Moho earliest arrival of 0. Instead, use your Kerbin earliest departure of 2075910.59. Alternatively, set your max delta-v to plot to something like 100 km/s. I would recommend the first solution, but both should resolve your issue.

Let me know how that works. Thanks for using KSP TOT!

EDIT: for going to Moho from Kerbin, you're probably going to need to update your options. Use a max delta-v of 20, 75 points per axis, and look over 2 synodic periods. Should work better than the defaults.

When I do so, I get something like this:

Edited January 12, 2014 by Arrowstar

[MaverickSawyer]

Huh... Every source I turn to has a different date to head for Moho... :/

[Arrowstar]

Huh... Every source I turn to has a different date to head for Moho... :/

Keep in mind that the optimal departure and arrival dates are not independent, so if you leave on one day, the best arrival day will also change. What other days/times have you seen thus far? Kerbin and Moho have a ~33 day synodic period, which means that every 33 days, the next Moho window opens up and the cost to going to Moho effectively repeats itself. Could it be that the numbers you've seen are off by about 33 days or so?

[MaverickSawyer]

One source put the first optimum day to depart at day 37, another put it at day 39, and TOT put the it at day 8. :/ I'm almost to day 37 now, and I've got a probe ready, but with a faulty launch window.

[Arrowstar]

I'll run a quick analysis for you starting at Day 36 and see what comes up. Hang tight.

EDIT: Just go now. Looks like you're moving out of the launch window if you're almost at Day 37.

Edited January 12, 2014 by Arrowstar

[MaverickSawyer]

Hmmm... that's a good chunk of the probe's dV (better than 60%)... Well, it's worth a shot! ;D

EDIT: Just plugged it into MechJeb... If I miss my Moho insertion burn, I'm going sundiving. It's pretty much taking em to a dead stop in space, then dropping me down the sun's gravity well. Should be fun!

Double edit: The burn dumped me into Kerbin's atmosphere, so clearly I did something really wrong... I'll try again when the Jool window opens in 12 days or so.

Edited January 12, 2014 by MaverickSawyer

[ormi]

Hi! Your problem is that no point in the porkchop plot is simultaneously A) less than the maximum delta-v in the options menu (Edit -> Options -> Max. Delta-V to Plot) and has an arrival date greater than its departure date (which is obviously necessary). Do not use a Moho earliest arrival of 0. Instead, use your Kerbin earliest departure of 2075910.59. Alternatively, set your max delta-v to plot to something like 100 km/s. I would recommend the first solution, but both should resolve your issue.

Let me know how that works. Thanks for using KSP TOT!

EDIT: for going to Moho from Kerbin, you're probably going to need to update your options. Use a max delta-v of 20, 75 points per axis, and look over 2 synodic periods. Should work better than the defaults.

When I do so, I get something like this:

http://i.imgur.com/8VV4jkZ.png

Thanks !

I now understand a lot more how to use it. I had tried setting the earliest arrival with the same date as the earliest departure without effect, but the fact is I did not realize at the time that the Earliest Departure Time and Earliest Arrival Time parameters are used as a reference for the plot, and the Synodic period for time scale.

From a user point of view, it still doesn't make sense that the optimiser (in the textbox at the bottom) give a result with a departure date in the past, even if the arrival date is future. In this case it may be better to replace the optimizer output by a message suggesting to tweak the options.

Anyway, I still have a problem :

After playing with the options, I finally have a nice graph (almost as important as the departure windows ) but the Computed Departure Burn windows seems weird.

I tested with a transfer from Kerbin to Duna starting at day 1 like the tutorial, the figures are the same, but the graph is buggy.

The problem (or another one...) appears to be present in the others tools to. The flyby throw some error after the particle swarm optimisation :

Starting matlabpool using the 'local' profile ... connected to 6 workers.

Swarming...Warning: Ignoring extra legend entries.
[> In legend at 286
  In psoplotbestf at 26
  In pso at 550
  In flyByManeuverSequencer>computeFlybyManSeqButton_Callback at 613
  In gui_mainfcn at 96
  In flyByManeuverSequencer at 42
  In @(hObject,eventdata)flyByManeuverSequencer('computeFlybyManSeqButton_Callback',hObject,eventdata,guidata(hObject))] 


Reached limit of 75 iterations

Best point before hybrid function: [5.6072e+07 3.9105e+06 5.9219e+06]

Turning over to hybrid function fmincon...


Local minimum possible. Constraints satisfied.

fmincon stopped because the size of the current step is less than
the selected value of the step size tolerance and constraints are 
satisfied to within the default value of the constraint tolerance.




Final best point: [5.6072e+07 3.9105e+06 5.9219e+06]

I reinstalled the MATLAB runtime without effect, what can I try now ?

[Arrowstar]

The first problem with the Compute Departure tool was a bug I've subsequently corrected. I'll push out a v0.11.1 release soon.

The second I can't duplicate. It looks like you just ran FMS with default settings. Have you seen it again?

EDIT: Found the problem with 2. Issue has been corrected, and v0.11.1 is building now.

Edited January 14, 2014 by Arrowstar

[Arrowstar]

KSP TOT v0.11.1 has been released. This version is a bug fix version that corrects the issues ormi found.

Please see the OP for more information and the download link.

[MaverickSawyer]

Hmmm... Is there any way you could add or develop a periapsis kick planner for those low TWR rockets with large burns to perform? I.E. take a burn, tell TOT you want to break it into four burns, and it spits out the four nodes needed to perform the overall burn in sequential orbits.

[ormi]

Hello !

The version 0.11.1 works much better form me, but all the bugs are not gone

The fix for the plot of the Departure Orbit in the compute departure windows works well, but if I switch to the Transfer Orbit display the graph is blank :

Cell contents reference from a non-cell array object.
Error in plotTransferOrbit (line 18)
Error in departDisplayGUI>plotDisplayPanel_SelectionChangeFcn (line 178)
Error in gui_mainfcn (line 96)
Error in departDisplayGUI (line 42)
Error in @(hObject,eventdata)departDisplayGUI('plotDisplayPanel_SelectionChangeFcn',get(hObject,'SelectedObject'),eventdata,guidata(get(hObject,'SelectedObject')))
Error in hgfeval (line 63)
Error in uitools.uibuttongroup/childAddedCbk>manageButtons (line 79)
Error while evaluating uicontrol Callback

And the departure graph doesn't show anymore :

Cell contents reference from a non-cell array object.
Error in plotBodyDepartOrbit (line 7)
Error in departDisplayGUI>plotDisplayPanel_SelectionChangeFcn (line 176)
Error in gui_mainfcn (line 96)
Error in departDisplayGUI (line 42)
Error in @(hObject,eventdata)departDisplayGUI('plotDisplayPanel_SelectionChangeFcn',get(hObject,'SelectedObject'),eventdata,guidata(get(hObject,'SelectedObject')))
Error in hgfeval (line 63)
Error in uitools.uibuttongroup/childAddedCbk>manageButtons (line 79)
Error while evaluating uicontrol Callback

I don't have the error in the Flyby sequencer anymore (and I indeed ran the FMS with default setting to reproduce the error more easily) and it seems to compute well. The problem is still with the plots : the transfer orbit works, but neither the departure orbit nor the flyby orbit. This time without any log entries.

I didn't try the others tools yet, I'll probably encounter the same sort of bug there... I'll keep you informed

Beside that, none of those bugs affects the calculations and it's a great tool really easy to use, especially with the new plugin

[Arrowstar]

Hmmm... Is there any way you could add or develop a periapsis kick planner for those low TWR rockets with large burns to perform? I.E. take a burn, tell TOT you want to break it into four burns, and it spits out the four nodes needed to perform the overall burn in sequential orbits.

This... is a great idea actually. I'll put it into my TODO list and look into implementing it this weekend. I already have an idea of how it needs to work from the algorithmic perspective. What kind of features/options would you like to see?

Hello !

The version 0.11.1 works much better form me, but all the bugs are not gone

The fix for the plot of the Departure Orbit in the compute departure windows works well, but if I switch to the Transfer Orbit display the graph is blank :

http://tama-k.brikabrok.net/ksp/transfer.png

Cell contents reference from a non-cell array object.
Error in plotTransferOrbit (line 18)
Error in departDisplayGUI>plotDisplayPanel_SelectionChangeFcn (line 178)
Error in gui_mainfcn (line 96)
Error in departDisplayGUI (line 42)
Error in @(hObject,eventdata)departDisplayGUI('plotDisplayPanel_SelectionChangeFcn',get(hObject,'SelectedObject'),eventdata,guidata(get(hObject,'SelectedObject')))
Error in hgfeval (line 63)
Error in uitools.uibuttongroup/childAddedCbk>manageButtons (line 79)
Error while evaluating uicontrol Callback

And the departure graph doesn't show anymore :

http://tama-k.brikabrok.net/ksp/departure.png

Cell contents reference from a non-cell array object.
Error in plotBodyDepartOrbit (line 7)
Error in departDisplayGUI>plotDisplayPanel_SelectionChangeFcn (line 176)
Error in gui_mainfcn (line 96)
Error in departDisplayGUI (line 42)
Error in @(hObject,eventdata)departDisplayGUI('plotDisplayPanel_SelectionChangeFcn',get(hObject,'SelectedObject'),eventdata,guidata(get(hObject,'SelectedObject')))
Error in hgfeval (line 63)
Error in uitools.uibuttongroup/childAddedCbk>manageButtons (line 79)
Error while evaluating uicontrol Callback

I don't have the error in the Flyby sequencer anymore (and I indeed ran the FMS with default setting to reproduce the error more easily) and it seems to compute well. The problem is still with the plots : the transfer orbit works, but neither the departure orbit nor the flyby orbit. This time without any log entries.

http://tama-k.brikabrok.net/ksp/fms_departure.png

http://tama-k.brikabrok.net/ksp/fms_flyby.png

I didn't try the others tools yet, I'll probably encounter the same sort of bug there... I'll keep you informed

Beside that, none of those bugs affects the calculations and it's a great tool really easy to use, especially with the new plugin

Okay, so I know what the issue is, just not why started occurring now. I haven't touched the plotting code for those applications in a very long time. In any event, it seems that the flag on the plot axes that manages the "overwrite" or "add" behavior of the plot when you render more things to the axis was getting reset every time I called plot3() (and some other functions). Basically I had to find all the instances of plot3() in my code and ensure that I set this particular flag correctly before each call. I don't understand why this started happening, but it did.

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.

Oh, just a heads up regarding v0.11 in general: for those of you using KSPTOTConnect, the IPAddressWhitelist text file now takes ranges of IP addresses. See the example provided with the software (in the GameData folder).

Thanks for the kind words, ormi! I really do appreciate hearing it.

Edited January 15, 2014 by Arrowstar

[MaverickSawyer]

This... is a great idea actually. I'll put it into my TODO list and look into implementing it this weekend. I already have an idea of how it needs to work from the algorithmic perspective. What kind of features/options would you like to see?

The main thing I would do if I was doing it would be to offer two options for plotting: number of periapsis kicks you want, and dV per periapsis kick. Choose one.

Also, to prevent the "I accidentally Mun" issue from cropping up, keep the apoapsis of the last orbit under 10,000 km. Shouldn't be hard, since it would be a very small burn after that to make escape.

[Arrowstar]

The main thing I would do if I was doing it would be to offer two options for plotting: number of periapsis kicks you want, and dV per periapsis kick. Choose one.

Also, to prevent the "I accidentally Mun" issue from cropping up, keep the apoapsis of the last orbit under 10,000 km. Shouldn't be hard, since it would be a very small burn after that to make escape.

I'm going to take it a step further, actually.

Number of burns to divide the burn into: check. This is obvious.

However, instead of making people specify delta-v per burn, I'll implement a more abstract "burn weighting" system where the user specifies the weight he/she desires each burn to have. Normalize by the sum of the weights and multiple by the total delta-v of the burn to split and you have your burn per delta-v. This will allow me to set up some nice defaults ("equal delta-v per burn", "front-loaded delta-v", "back-loaded delta-v", "delta-v for specified maximum burn time", "user-defined", etc).

I'm not going to do anything about the "don't hit the Mun" problem. People need to do the analysis for themselves to ensure that they don't go hitting anything. That's the fun in engineering!

Thanks for helpful suggestions.

[Arrowstar]

I made lots of good progress tonight on the perigee kick algorithm. Given a starting orbit, a delta-v vector, and the desired number of burns, the original one burn is split into multiple burns.

There are multiple available strategies. The delta-v can be split evenly, "front-loaded" (more delta-v burned earlier), or "back-loaded" (more delta-v burn later). In addition, the user will be able to specify their own custom weighting, and a few other "optimized" weightings (minimizing/maximizing certain quantities) will also be available.

Here are some examples of the first three strategies. The initial orbit is a 100x100 km equatorial orbit, and the burn to be split up is 1 km/s in the prograde direction (think Duna ejection burn).

Equally Split

Front Loaded

Back Loaded

What do you guys think?