[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Drew Kerman]

Did this last nite but for some reason was exhausted and had to crash before I could post it. Edited Word file

[salajander]

On 5/24/2016 at 7:30 PM, Arrowstar said:

Thanks, guys!  I look forward to your comments, suggestions, and feedback.

Since it's the default for KSP,  and converting between them can be tedious, I'd love for all dates and times to be Kerbin, not Earth.

[Arrowstar]

2 minutes ago, salajander said:

Since it's the default for KSP,  and converting between them can be tedious, I'd love for all dates and times to be Kerbin, not Earth.

As far as I'm aware, Kerbin time is what's used. What prompts you to believe otherwise, if I might ask?

[salajander]

In the MFMS data on page 5, the Kerbin departure date is "Year 2, Day 109 10:25:19.242"; Kerbin days are 6 hours long, so 10 o'clock makes no sense. This leads me to believe all the other dates and times are also Earth time.

I'd also love KSP TOT to default to Kerbin time (or at least remember my preference). I've always had a difficult time getting the MFMS to give reasonable outputs when using Kerbin time (there's been a few posts by others about this, I'll try to dig one up), which I think is some internal confusion about the time standard used and the MFMS's definition of "days", perhaps.

Edited May 26, 2016 by salajander

[Arrowstar]

1 minute ago, salajander said:

In the MFMS data on page 5, the Kerbin departure date is "Year 2, Day 109 10:25:19.242"; Kerbin days are 6 hours long, so 10 o'clock makes no sense. This leads me to believe all the other dates and times are also Earth time.

I'd also love KSP TOT to default to Kerbin time (or at least remember my preference). I've always had a difficult time getting the MFMS to give reasonable outputs when using Kerbin time (there's been a few posts by others about this, I'll try to dig on up), which I think is some internal confusion about the time standard used and the MFMS's definition of "days", perhaps.

Oh oh oh. Yes, you're right, KSPTOT does default to Earth time. I had it mixed around in my head. Thanks for pointing it out. 

To be honest, I don't prefer Kerbin time. The days and hours numbers make most sense to me as arbitrary units of time without attaching significance to something physical, like the rotation of the planet. I do see why some people like it, though, which is why I have the setting option there. I think that it'll probably stay defaulted to Earth time for now, though. 

That said, it might be time to store application wide settings like this in an external file that can be read in at start up and have individual settings stored when you alter them. Would something like that work?  And what other settings might you want to include in such a file?

[salajander]

Yeah, the MFMS doesn't play well with Kerbin time.

Here's a simple Kerbin-Eve setup in MFMS, using Earth time:

If I change the time system to Kerbin, and adjust the min/max flight times accordingly, I get this:

The delta-V information is the same, but the plot is way out of whack.

55 minutes ago, Arrowstar said:

To be honest, I don't prefer Kerbin time. The days and hours numbers make most sense to me as arbitrary units of time without attaching significance to something physical, like the rotation of the planet. I do see why some people like it, though, which is why I have the setting option there. I think that it'll probably stay defaulted to Earth time for now, though. 

Well, I'm used to looking at Kerbin times when using KSP, so when KSP TOT defaults to Earth times it gets confusing for me. De gustibus non est disputatum.

58 minutes ago, Arrowstar said:

That said, it might be time to store application wide settings like this in an external file that can be read in at start up and have individual settings stored when you alter them. Would something like that work?  And what other settings might you want to include in such a file?

Time system, for sure. But once you've done one preference, there are tons of others that might be useful. Off the top of my head:

• everything in the Edit -> Options menu in the main program
• everything in Script -> Execution Settings in the Mission Architect
• perhaps the last bodies selected in the main program? the last waypoints in the MFMS?

[Arrowstar]

44 minutes ago, salajander said:

Yeah, the MFMS doesn't play well with Kerbin time.

Here's a simple Kerbin-Eve setup in MFMS, using Earth time:

If I change the time system to Kerbin, and adjust the min/max flight times accordingly, I get this:

The delta-V information is the same, but the plot is way out of whack.

Time system, for sure. But once you've done one preference, there are tons of others that might be useful. Off the top of my head:

• everything in the Edit -> Options menu in the main program
• everything in Script -> Execution Settings in the Mission Architect
• perhaps the last bodies selected in the main program? the last waypoints in the MFMS?

Thanks for reporting, issue has been resolved!  I think I'll release v1.5.4 this weekend (on the new MCR), as it has a number of bug fixes, including this one and some others in Mission Architect.  Probably best to get those out to the community sooner rather than later, particularly since no one has complained about the v1.5.4 pre-release being horribly broken or anything.

And thanks for the feedback on the setting file.  I'll definitely take a look at this.  It should be easy to whip up, but we'll see what actually happens.  If not for v1.5.4, then perhaps v1.5.5.

[Arrowstar]

12 hours ago, Gaiiden said:

Did this last nite but for some reason was exhausted and had to crash before I could post it. Edited Word file

Thanks for the good notes!  I'm reviewing now.

[russm]

3 hours ago, Arrowstar said:

Thanks for reporting, issue has been resolved!  I think I'll release v1.5.4 this weekend (on the new MCR), as it has a number of bug fixes, including this one and some others in Mission Architect.  Probably best to get those out to the community sooner rather than later, particularly since no one has complained about the v1.5.4 pre-release being horribly broken or anything.

Oh, that reminds me...

When I try to run KSPTOT_v154_prerelease1 it fails to launch, complaining that it can't find version 9.0 of the MATLAB runtime ("Attempting to load mclmcrrt9_0.dll"). I installed MCR_R2016a_win64_installer.exe from your link, and the only mclmcrrt DLL it's given me is /Program Files/MATLAB/MATLAB Runtime/v901/runtime/win64/mclmcrrt9_0_1.dll

I'm assuming there's been a point release and your MATLAB is linking against v900 but v901 is all that's available for download now, but it seems a little surprising that the MCR would be so fragile in the face of point releases.

Also, FWIW, I'm running under Wine, so I can't discount the problem being at my end

 

UPDATE:

If I fake out the installed version to look like v900 (rename the DLLs from mclfoo9_0_1.dll to mclfoo9_0.dll) and rename the top level install dir from v901 to v900, launching KSPTOT shows a dialog saying

"Your application should run on MATLAB Runtime version 9.0.0 . The installed MATLAB Runtime is 9.0.1"

Edited May 27, 2016 by russm
more info

[Arrowstar]

Hi everyone,

In preparation for the (hopeful!) release of v1.5.4 this weekend, I wanted to put out another pre-release that will hopefully be the actual release build.  This pre-release, like the other one, requires the R2015b version of the MCR.  If you are interested, please give this new executable a whirl and let me know if you run into any problems.  Thanks!

Downlink link: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v154_prerelease2.zip

Edited May 27, 2016 by Arrowstar

[russm]

15 minutes ago, Arrowstar said:

This pre-release, like the other one, requires the R2014b version of the MCR.

Ummm, is that meant to be R2016a? (I'm unable to launch it, with the same error as prerelease1)

[russm]

On the MCR download page the only R2016a listed is 9.0.1, but it has an explicit footnote "MATLAB Runtime 9.01, for R2016a, is intended to work with MATLAB 9.0, which is also R2016a."

So I guess either MathWorks have duffed the point release compatibility, or something about the Wine runtime is stopping it from working.

[Arrowstar]

23 minutes ago, russm said:

Ummm, is that meant to be R2016a? (I'm unable to launch it, with the same error as prerelease1)

Oh shoot, meant to say R2015b and typed the wrong thing. I corrected it, thanks for the note!

Try downloading this MCR and let me know if you have problems. :-) 

[russm]

Ah, crap.

Yes, using the R2015b MCR gets past the problem I was having, but then it dies with

wine: Call from 0x7b44db78 to unimplemented function setupapi.dll.CM_Get_DevNode_Status, aborting

which is Not Your Problem. Looks like we're back to Windows-only.

[Arrowstar]

1 minute ago, russm said:

Ah, crap.

Yes, using the R2015b MCR gets past the problem I was having, but then it dies with

wine: Call from 0x7b44db78 to unimplemented function setupapi.dll.CM_Get_DevNode_Status, aborting

which is Not Your Problem. Looks like we're back to Windows-only.

Aw, drat.  Did you follow the instructions in the OP regarding the use of WINE?  I've copied them below.  There is no guarantee these will work, but at least one person has had success with them.

On 5/3/2016 at 0:39 PM, salajander said:

1. Install WINE (I installed the latest staging build from https://www.winehq.org/download/)
2. Install cabextract and ensure it's in your PATH
   1. On OS X, use homebrew or macports; e.g., 'brew install cabextract'
   2. On Linux, use your distro's package manager (apt, yum, etc.)
3. Install winetricks: https://wiki.winehq.org/Winetricks
4. Install the native VC++ runtime: 'winetricks vcrun2012'
5. Install the (Windows!) MCR: 'wine MCR_R2014b_win64_installer.exe'
6. Launch KSPTOT! : 'wine KSPTrajectoryOptimizationTool.exe'

[russm]

4 minutes ago, Arrowstar said:

Aw, drat.  Did you follow the instructions in the OP regarding the use of WINE?  I've copied them below.  There is no guarantee these will work, but at least one person has had success with them.

Yep, that's how I've been running v153. Looks like somewhere between 8.4 and 9.0 they've started doing something that doesn't work under Wine. I've had a poke around in Wine's compatibility settings to see if I could get it going, with no luck.

I'd be curious to see if it fails for any other Wine users - I'm running it on a Linux box with no local display so the MCR does a lot of complaining about not being able to set up CUDA before it dies. OSX or Linux with GPU users *might* have more luck than me.

[Arrowstar]

1 minute ago, russm said:

Yep, that's how I've been running v153. Looks like somewhere between 8.4 and 9.0 they've started doing something that doesn't work under Wine. I've had a poke around in Wine's compatibility settings to see if I could get it going, with no luck.

I'd be curious to see if it fails for any other Wine users - I'm running it on a Linux box with no local display so the MCR does a lot of complaining about not being able to set up CUDA before it dies. OSX or Linux with GPU users *might* have more luck than me.

Bummer!  Sorry about that, not much I can do.  Can you at least run it on Windows?

[russm]

3 minutes ago, Arrowstar said:

Bummer!  Sorry about that, not much I can do.  Can you at least run it on Windows?

No worries, like I said this is clearly Not Your Problem.

Time to set up a new Windows VM I guess...

[russm]

@Arrowstar Any chance you could push the current state of KSPTOT up to your github repo? I'm going to have a shot at making it usable under GNU Octave. It'll certainly be non-GUI (since Octave doesn't support any of the GUIDE stuff), but I'd be happy to be able to run the backend bits from the command line.

EDIT: oh never mind, I just realised you include source in the non-prerelease bundles.

Edited May 27, 2016 by russm
learned to read

[Arrowstar]

7 hours ago, russm said:

@Arrowstar Any chance you could push the current state of KSPTOT up to your github repo? I'm going to have a shot at making it usable under GNU Octave. It'll certainly be non-GUI (since Octave doesn't support any of the GUIDE stuff), but I'd be happy to be able to run the backend bits from the command line.

EDIT: oh never mind, I just realised you include source in the non-prerelease bundles.

Just a heads up, you may have some issues with this. I use some specialised functions in the code that may not be in Octave. There are also a number of places where the GUI is tied to the "engine" code quite tightly. It may be very hard to unravel that. Oh, and I use a few compiled functions for Lambert solving and the like too, not sure if Octave will know what to do with those. 

[DivisionByZero]

Arrowstar: I was working with the new prerelease 2 and everything seems to be working well.  I haven't found any bugs yet.  I have to say the new tutorial is also very helpful.  Having some explanation of the "selective SOI" business is really good.

There's a feature/calculation I was going to suggest: I had started doing a mission architect plan for Duna but because of the launch windows, it's going to involve a lot of time at Duna, >1 kerbal year.  I popped this in the mission plan as a "coast to UT" activity but it involves a lot of orbits.  I suspect the mission-architect window is drawing all the orbits because I noticed that trying to rotate the map is no where near as smooth as the other mission segments. 

I would like to suggest you consider a change to the code: have the code only draw up to one full orbital period if there are no maneuvers involved.  Otherwise, one can split the mission architect file into two parts to avoid the long waiting period in the middle.  I was trying to have MA keep track of all delta-V requirements for the entire mission, though, so I didn't do this originally. 

[Arrowstar]

15 hours ago, DivisionByZero said:

I would like to suggest you consider a change to the code: have the code only draw up to one full orbital period if there are no maneuvers involved.  Otherwise, one can split the mission architect file into two parts to avoid the long waiting period in the middle.  I was trying to have MA keep track of all delta-V requirements for the entire mission, though, so I didn't do this originally. 

So it's not a bad idea, but unfortunately it's really not possible.  What gets plotted at every instant in time is not actually the Keplerian orbit definitions but a "state log" of X, Y, and Z positions that Mission Architect stores.  (Lots of other data gets stored in the state log too, including a time stamp, velocity, the body being orbited, things like that.)  Point is, the object getting plotted, this log, has no idea if an orbit goes around more than once or anything like that.  All it knows to do is plot points, and that's what it does.  It would take a pretty fair architecture change to alter this behavior reliably, sadly.

For now, the easy solution is to just split your missions into two parts and don't model the coast in between.  Since nothing is going on there, I don't see any reason for that to get modeled in the first place.

[Arrowstar]

Hi everyone,

I'm pleased to announce this evening the release of the KSP Trajectory Optimization Tool v1.5.4!  This is primarily a bug-fix release that includes the following changes:

• KSPTOT now runs on a new MATLAB Compiler Runtime, R2015b x64!  This requires an install of this runtime to use KSPTOT.  Please see the OP or this link to download the new MCR.
• Bug fixes for the Mission Architect Comm. Network Analysis Tool's pathfinding algorithm;
• A bug fix in the Multi-Flyby Maneuver Sequencer's use of the compiled Lambert solver when using Kerbin time;
• Fixes to a bug in Mission Architect orbit angle constraints (RAAN, argument, etc).
• Additions of new constraints in Mission Architect: prograde/normal/radial distance from Other Spacecraft, and Relative Velocity to Other Spacecraft
• Addition of new Mission Architect Graphical Analysis tasks: prograde/normal/radial distance from Other Spacecraft, and Relative Velocity to Other Spacecraft
• A few other minor tweaks here and there.

The aforementioned new Mission Architect tutorial will be included in the download package at a later date, as I'm still working on it and I'd like another round of feedback before I release it.  Thanks to everyone who's take a look at it thus far!

The global settings file that was discussed in this thread will be evaluated for the next version of KSPTOT, likely called v1.5.5.

Please let me know if you have any questions or find any bugs!  Thanks!

[Arrowstar]

Also, everyone, just a note that I've updated the KSPTOT Mission Architect tutorial I'm currently working on, "Solar System's Edge."  The new tutorial package is located here:

https://dl.dropboxusercontent.com/u/29126891/Solar%20System%20Edge%20-%20MA%20Tutorial.zip

Could I please get some feedback on this?  In particularly, what I'm looking for people to go through the tutorial with Mission Architect and verify that all the steps work.  Obviously I've done this myself, but verification is important in this regard.  It would also be great if reviewers could point out what requires additional explanation and what isn't clear.

Thanks, everyone!

[SAI Peregrinus]

Trying the Solar System's Edge Tut. Went off the rails at the Rendezvous Maneuver 1 burn and smacked into Plock. Re-ran tut.Got a better incoming trajectory, but of course that throws the RMS input values way off. I continued the naive way mashing the optimization until I got an OK orbit, though of course running the RMS myself would have been far better. But since there's no RMS tutorial I tried to pretend I was new to the program and had only done the Laythe mission tutorial included in the KSP-TOT zip.

A few times I got the error:

There was an error optimizing the misson script:

Subscript indicies must either be real positive integers or logicals.

from the optimizer. Stopping it just before the iteration that caused the error & tweaking values helped, though a real newbie would probably have given up...

I've linked each stage I went through below.

https://drive.google.com/file/d/0B-c_PUlJR9sQdHFWek9iX2xkUEE/view?usp=sharing