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

[Drew Kerman]

Bummer, was hoping to have time to check out the newest pre release but ran out. I’ll be back home on Jan 4th

[Arrowstar]

On 12/18/2018 at 11:00 PM, KonohanaSakuya said:

Sure thing, thank you! Sorry for taking a bit to get back. I'll include the bodies.ini file too, in case you don't have a copy for OPM, for the sake of reproducing it if somehow not just a run-of-the-mill ID-10 T error. My intuition is telling me that there's some operator error going with the translation from the burn params in the departure planner to inserting it into MA, or something like that.

.mat file:  Mun-Minus_Test.mat

OPM bodies file: bodies.ini

So thanks for sharing this.  I'm not going to be able to take a look until early January, unfortunately.  I didn't have a chance to get to it today and the holidays are always a busy time for me.  Keep working at it and if you're still struggling I'll definitely provide a helping hand after the end of December.

[KonohanaSakuya]

Still, I'm grateful that you'll look over it, full stop. Some more testing was done, now that I got home. I'm putting this out here now for you to look over later, or if maybe some mistake I'm making jumps out at anyone else in the mean time.

I'm starting with looking at phase angles and such. At the specified time for the departure burn (UT 1748978.7063; hereafter UT α) it looks right in-game and departure planner, but in MA the angle is off considerably. (to save space, I'm only showing it in DP)

Departure position/trajectory in DP, with specified orbital vector ΔV at UT α
Departure position/trajectory in MA, with the same burn at UT α.
I can get a better transfer with considerable manual fudge-ery, but that's aside the point. The burn doesn't pass the smell test to me, either.

There's another discrepancy I found doing this, too: When I plug the orbit into DP, I tell it to use my anom/epoch info:

Note how the epoch is UT α, and the departure time given to DP is UT α as well. Therefore, regardless of MA's accuracy here, DP should acknowledge that at UT α that my anomaly is 284° ; however, it still says my burn anomaly is 14.5° instead, despite still being at UT α. So at this point I'm more than a little puzzled.

Once more, I cannot thank you enough for any help you give. I deeply appreciate it.

[Arrowstar]

6 hours ago, KonohanaSakuya said:

Still, I'm grateful that you'll look over it, full stop. Some more testing was done, now that I got home. I'm putting this out here now for you to look over later, or if maybe some mistake I'm making jumps out at anyone else in the mean time.

I'm starting with looking at phase angles and such. At the specified time for the departure burn (UT 1748978.7063; hereafter UT α) it looks right in-game and departure planner, but in MA the angle is off considerably. (to save space, I'm only showing it in DP)

Departure position/trajectory in DP, with specified orbital vector ΔV at UT α
Departure position/trajectory in MA, with the same burn at UT α.
I can get a better transfer with considerable manual fudge-ery, but that's aside the point. The burn doesn't pass the smell test to me, either.

There's another discrepancy I found doing this, too: When I plug the orbit into DP, I tell it to use my anom/epoch info:

Note how the epoch is UT α, and the departure time given to DP is UT α as well. Therefore, regardless of MA's accuracy here, DP should acknowledge that at UT α that my anomaly is 284° ; however, it still says my burn anomaly is 14.5° instead, despite still being at UT α. So at this point I'm more than a little puzzled.

Once more, I cannot thank you enough for any help you give. I deeply appreciate it.

I had a spare 15 minutes floating around, so I took a look at your MAT file today (but haven't had a chance to dig into the pictures you sent).  My advice would be to set your objective function to minimize the distance to Minmus at event 9 and then optimize the coast time of event 7 to be whatever your desired stay duration is +/- one half revolution around the Mun.  Without looking, I'm guessing that you're not hitting some orbit angle perfectly and that's throwing off the departure time or true anomaly or whatnot.  In any event, when going to other bodies, minimizing the distance to those bodies and optimizing the coast duration prior to the burn is almost always a good idea.

Give that a go for now.  I'll try to dig into more in a week or two.  Happy orbiting!

[RaceToTheMun]

How do I set the time of the program to the time I was on Ksp. For example its says departure time is somehow around year 1 but on my save file it says year 21. What do I do to this will I have to start all over again

[Arrowstar]

17 hours ago, RaceToTheMun said:

How do I set the time of the program to the time I was on Ksp. For example its says departure time is somehow around year 1 but on my save file it says year 21. What do I do to this will I have to start all over again

There is.  Can you share a screenshot of what you're having difficulty with?

[RaceToTheMun]

On 12/27/2018 at 1:15 PM, Arrowstar said:

There is.  Can you share a screenshot of what you're having difficulty with?

no need. Just saying if Ksp tot records my save file time

[Arrowstar]

19 hours ago, RaceToTheMun said:

no need. Just saying if Ksp tot records my save file time

So nothing in the software "records" your save file time.  However, since you enter times manually when you use KSPTOT, there's really no need to.  You can also have it pull the time from KSP itself or from a save file directly. It shouldn't be a problem for you to keep your existing save. :)

[RaceToTheMun]

does ksp tot use earth time or kerbin time?

 

[Arrowstar]

2 hours ago, RaceToTheMun said:

does ksp tot use earth time or kerbin time?

 

It  can use either.  That option is selected on the main UI's menu bar (the Edit menu).

[Arrowstar]

Hi everyone!

Tonight I'm posting the 5th pre-release of KSPTOT v1.6.1.  This pre-release is primarily focused on Launch Vehicle Designer (LVD) and adds the following functionality:

• Adds a new integrator, DOP853, to the LVD event options.
• New LVD constraint type: Stopwatch value.
• Speed improvements to the script propagator.
• Some other bug fixes here and there.

I've also included with this pre-release package an LVD example MAT file that:

1. Demonstrates how you could model asparagus staging in LVD (and by extension, many other common staging techniques);
2. Provides a full up example mission that launches from Kerbin, flies to the Mun, lands on the Mun, stays on the Mun for some time, launches from the Mun, flies back to Kerbin, and lands back on Kerbin.

As usual, please let me know if you have any questions or you find any bugs.  This will probably be the v1.6.1 release unless there are any comments.  My goal is to put out the v1.6.1 release this weekend, so please let me know if you find anything important.

Thanks and happy orbiting!

[Arrowstar]

Hi everyone!

So I lied.  The past few days I've really been focused on improving the performance of LVD.  I know it usually takes a fair bit longer to run a script in LVD than in Mission Architect (which is why MA is still the recommended tool for pure in-space mission analysis and design).  I had a few "shower thoughts" yesterday on enhancements I could make and I wanted to share those with everyone in one final pre-release before this weekend, when I'm still planning on having the formal release of KSPTOT v1.6.1 drop.  In light of that, here is KSPTOT v1.6.1 pre-release 6.

Change log (all work is in LVD):

• Performance enhancements in script execution everywhere.  More intelligent caching of information that doesn't change frequently during a mission, such as engine to tank connection states.  My asparagus staging example runs about 30% faster today than a did a few days ago.
• A new "Simulation" menu that allows users to run the LVD mission script as-is.  Useful for refreshing information or debugging.  Has a Cntrl-P hotkey so you don't need to use the menu directly.
• Just about every dialog box will open faster now due to a serious performance improvement in the way that undo/redo caching works now.  (That long pause before the Edit Event dialog opens up?  Yeah, that's LVD serializing the current application state.  I made that bit go much faster.)
• Added the ability to turn off certain force models for some events.  Allows for some performance improvements if, say, you know that your event will never be thrusting: don't bother calling the Thrust force model in this case.
  • Also included two new mission validators (that populate the warnings & errors segment in the lower right): a check to see if the throttle is greater than 0% for events where the Thrust model is turned off, and a check to see if the vehicle is in atmosphere but drag is turned off.
• Finally finished up the Normal force model, which can be used to keep an object on the surface of a body (altitude = 0).  This allows for modeling of aircraft on a runway (anyone want to try modeling SpaceShipOne?), rovers on the surface of a planet, and really anything that touches the surface of any body.

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

[Drew Kerman]

I'm back! Since you said you want to get the release out this weekend I will devote today to working on my latest ascent trajectory and let you know if I come across any issues or have further suggestions

[linuxgurugamer]

A few questions.

What sort of learning curve is there to this?

Is it very time consuming to use this?

Is there an advantage to have this running while flying (on a different monitor)?

Thx

[Drew Kerman]

57 minutes ago, linuxgurugamer said:

What sort of learning curve is there to this?

I'd compare it to Blender. It's pretty steep in the beginning to get a handle on where everything is and what everything does and how to put that together to make it do what you want - but once you work through a couple of use cases things get easier and easier and using the tool becomes very rewarding. The wiki has plenty of tips and help, there are example files and the author is very helpful in guiding you through problems

59 minutes ago, linuxgurugamer said:

Is it very time consuming to use this? 

Can't really say. The more complicated the mission the more time you'll spend planning it. The more experience you have the faster this will go. I'd say as long as you're starting off with small mission scopes and adding complexity as you learn, the time needed will always be minimal

1 hour ago, linuxgurugamer said:

Is there an advantage to have this running while flying (on a different monitor)?

Yea, it has a cool Mission Control Telemetry interface that can provide real time data but you may already have that in-game with various mods. The real reason though is you're going to want to be re-optimizing your mission plan as you execute it, so you'll be importing new orbital data from the game and refining things in the program, usually after each event state in the mission

[Drew Kerman]

okay @Arrowstar I've got some issues for you that need to be resolved before I can continue:

Bugs

• Close button in the Edit Launch Vehicle does not work sometimes. To reproduce, open LVD and just make three copies of the engine already made for the spacecraft.
• Directly related to the above bug, after you close the window (X window button still works, Esc does not) you also cannot open the the window to edit the initial vehicle and stage states
• Tab movement in the Edit Engine window skips over the engine dropdown and returns after the Sea level ISP
• What is up with the engine list re-sorting after editing an engine? I notice it only when dealing with engines of similar names. See this LVD case file. If you open it and change something for SRB-S #1 then it will be moved to the bottom of the list. Edit any of the first three engines and they'll stay where they are
• My case file also has the Close button issue, if you want another example
• Also using my case file, it seems the SRB-S engines are all associated with one another somehow. I did create them by using the Copy Engine right-click option from the same initial SRB-S entry then renamed them #1-#4. If you go to the Edit Launch Vehicle and Stage States window, you can double-click to change the states of the first three engines but not the four SRB-S engines. If you select one of the SRB-S engines then click the checkbox, you'll notice that all the SRB-S engines are now active/inactive
• There is still a Get Orbit right-click option in the Edit Initial State dialog. Doing this will replace all the fields with orbital properties
• If you open the InjectToGTO example file, disable the first stage engine but then hit Cancel instead of Save, the engine is still disabled

Suggestions

• Add throttle mix/max to the output text of spacecraft details if it is changed from the default 0-100
• The data for Alt/Lat/Lng needed for the initial state is available from the game/SFS so maybe that option could remain but just pull the proper data needed
• Still annoyed a bit by the last dialog that pops up if you exit KSPTOT without closing LVD or MA first when they have open unsaved files. It asks if you want to continue and clicking "no" still exits the program. You already get the option to cancel the closing in the first dialog, so that makes the second one redundant. I realize it may just be doing this because you're sending the command to tell the window to close, but could the dialog be skipped over if the program is closing the window instead of the user? Or, it could just ask the user to whether they want to save or not

Questions

• How best to setup using multiple engines per stage (like a Falcon 9 or numerous radial boosters)? In the case file I had created separate engines for each booster, but I also created just a single tank even though all four boosters have their own. I just combined the fuel mass for the tank - I guess I could do the same for the engines and just create a single SRB-S entry. If I do so, I would be combining only the thrust and not also the ISP correct? I see you do this in your asparagus staging example but not sure what the original engine was so can't tell if you only combined the thrust and not the ISP. My understanding though would say the ISP would remain the same
• What exactly does an inactive stage mean? Does that only refer to the mass of the stage? I see you deactivate a stage in examples but also kill the fuel connection and engine. Is that just being explicit for people to see what is going on? Is setting a stage to inactive also effectively telling the simulation the engines and tanks associated with that stage are now inactive as well?

[Arrowstar]

6 hours ago, Drew Kerman said:

okay @Arrowstar I've got some issues for you that need to be resolved before I can continue:

Bugs

• Close button in the Edit Launch Vehicle does not work sometimes. To reproduce, open LVD and just make three copies of the engine already made for the spacecraft.
• Directly related to the above bug, after you close the window (X window button still works, Esc does not) you also cannot open the the window to edit the initial vehicle and stage states
• Tab movement in the Edit Engine window skips over the engine dropdown and returns after the Sea level ISP
• What is up with the engine list re-sorting after editing an engine? I notice it only when dealing with engines of similar names. See this LVD case file. If you open it and change something for SRB-S #1 then it will be moved to the bottom of the list. Edit any of the first three engines and they'll stay where they are
• My case file also has the Close button issue, if you want another example
• Also using my case file, it seems the SRB-S engines are all associated with one another somehow. I did create them by using the Copy Engine right-click option from the same initial SRB-S entry then renamed them #1-#4. If you go to the Edit Launch Vehicle and Stage States window, you can double-click to change the states of the first three engines but not the four SRB-S engines. If you select one of the SRB-S engines then click the checkbox, you'll notice that all the SRB-S engines are now active/inactive
• There is still a Get Orbit right-click option in the Edit Initial State dialog. Doing this will replace all the fields with orbital properties
• If you open the InjectToGTO example file, disable the first stage engine but then hit Cancel instead of Save, the engine is still disabled

Suggestions

• Add throttle mix/max to the output text of spacecraft details if it is changed from the default 0-100
• The data for Alt/Lat/Lng needed for the initial state is available from the game/SFS so maybe that option could remain but just pull the proper data needed
• Still annoyed a bit by the last dialog that pops up if you exit KSPTOT without closing LVD or MA first when they have open unsaved files. It asks if you want to continue and clicking "no" still exits the program. You already get the option to cancel the closing in the first dialog, so that makes the second one redundant. I realize it may just be doing this because you're sending the command to tell the window to close, but could the dialog be skipped over if the program is closing the window instead of the user? Or, it could just ask the user to whether they want to save or not

Questions

• How best to setup using multiple engines per stage (like a Falcon 9 or numerous radial boosters)? In the case file I had created separate engines for each booster, but I also created just a single tank even though all four boosters have their own. I just combined the fuel mass for the tank - I guess I could do the same for the engines and just create a single SRB-S entry. If I do so, I would be combining only the thrust and not also the ISP correct? I see you do this in your asparagus staging example but not sure what the original engine was so can't tell if you only combined the thrust and not the ISP. My understanding though would say the ISP would remain the same
• What exactly does an inactive stage mean? Does that only refer to the mass of the stage? I see you deactivate a stage in examples but also kill the fuel connection and engine. Is that just being explicit for people to see what is going on? Is setting a stage to inactive also effectively telling the simulation the engines and tanks associated with that stage are now inactive as well?

Bugs:

• Fixed in next release.
• Fixed in next release.
• I did a pass of all the LVD UIs and made sure that tab orders made sense everywhere.  Should not be a problem any more.  Thanks for noticing this!
• Engines are organized by stage because they are stored in Stage objects that are arranged in a particular order. Anyway, I tried it out and the edited engine gets moved to the bottom of the list (well, the bottom of the part of the this that has engines for that stage).  This is because the engine is actually destroyed and recreated when you edit it.  There were some issues with just modifying the engine and its associated state many moons ago when I wrote that code, if I recall.  In any event, it should be transparent to the user, but I can understand why it would look weird for it to be doing what it's doing now.  I would have to think about how to change this to get the behavior of staying in the same spot... it's not straightforward the way it's set up now.
• Fixed in next release.
• I gave the Initial State UI a big overhaul.  Now when you change the dropdown from one element set to another, it converts the numbers in the boxes too.  And if you try to import an orbit from KSP or the orbit clipboard when you're on Body Fixed elements, it converts those to Body Fixed instead of (erroneously) leaving them as Keplerian numbers.
• Fixed in next release.  (All of the engine issues were really just one big issue under the hood that correcting resolved.)

Suggestions:

• Good idea, added for next release.
• Implemented for next release as I explained above.
• So... yeah.  This is hard because the first dialog box you see is generated from the main KSPTOT UI.  If you tell it to close windows, then it issues close commands to the other UIs.  However, those UIs aren't aware of who is issuing the close command, they just do it.  I'll keep thinking on this for the future, there's probably a way to get things to communicate, I just need to find a way that isn't a pain in the neck to implement or maintain.

Questions:

• For best performance, try to combine tanks and engines as much as possible.  So if you have 9 of the same engines on your actual vehicle, just make one Super Engine with 9x the thrust and the same Isp.  If you have multiple types of engines, you can either create one Super Engine for each type or create one single Super Engine with the total thrust of all the real engines and the mass flow rate-weighted Isp.  I can explain how you do this if you'd like, but the former option might just be easier to implement. 
  • As far as tanks go, where tanks exist on the same physical stage, try to combine those.
• An inactive stage:
  • Will not have its dry mass included in the mass of the vehicle;
  • Will not allow access to any engines onboard that stage (active or inactive);
  • Will not allow access to any tanks onboard that stage and will not include the mass of anything in those tanks in the total vehicle mass; and
  • Will not allow engine to tank connections from stages that are inactive.

Hope all that helps!  Let me know if you have any questions or you find something else buggy.  Thanks!

[Arrowstar]

9 hours ago, linuxgurugamer said:

A few questions.

What sort of learning curve is there to this?

Is it very time consuming to use this?

Is there an advantage to have this running while flying (on a different monitor)?

Thx

Hi!  KSPTOT author here.  @Drew Kerman gave you a pretty good reply, but I wanted to let you know that if you have questions you can post here and I'll do my best to answer them as time allows.  Happy orbiting.

[Drew Kerman]

11 minutes ago, Arrowstar said:

If you tell it to close windows, then it issues close commands to the other UIs.  However, those UIs aren't aware of who is issuing the close command, they just do it. 

Yup this is exactly what I thought was happening. Minor issue.

Chuck me that bug fix release and I can move along again and get you any more issues. I did encounter a bit more oddness in trying to make my first two states but that may have cleared up with the engine coding getting sorted, so I haven't done any additional work on the ascent yet

[Arrowstar]

3 minutes ago, Drew Kerman said:

Yup this is exactly what I thought was happening. Minor issue.

Chuck me that bug fix release and I can move along again and get you any more issues. I did encounter a bit more oddness in trying to make my first two states but that may have cleared up with the engine coding getting sorted, so I haven't done any additional work on the ascent yet

Sounds good.  It's building now, I'll post it here when it's finished.

[linuxgurugamer]

17 minutes ago, Arrowstar said:

Hi!  KSPTOT author here.  @Drew Kerman gave you a pretty good reply, but I wanted to let you know that if you have questions you can post here and I'll do my best to answer them as time allows.  Happy orbiting.

I will.  Ill be looking at this as time allows.  @Drew Kerman said that if I kept it open that it can talk to KSP real time?  If so, then that is so ething I am going to be interested in.

[Drew Kerman]

2 minutes ago, linuxgurugamer said:

if I kept it open that it can talk to KSP real time?  

forgot to mention it can also directly inject maneuvers you calculate with it as maneuver nodes in the game. Aw yea, it's great

[Arrowstar]

3 minutes ago, linuxgurugamer said:

I will.  Ill be looking at this as time allows.  @Drew Kerman said that if I kept it open that it can talk to KSP real time?  If so, then that is so ething I am going to be interested in.

Yes.  On the main KSPTOT window you'll see a menu for "KSP Real Time System".  That's the entry way to the "mission control" side of the house that lets you pull information from the game as you fly. 

[Arrowstar]

48 minutes ago, Drew Kerman said:

Yup this is exactly what I thought was happening. Minor issue.

Chuck me that bug fix release and I can move along again and get you any more issues. I did encounter a bit more oddness in trying to make my first two states but that may have cleared up with the engine coding getting sorted, so I haven't done any additional work on the ascent yet

Here you go, @Drew Kerman.  This is the build with your bug reports and suggestions incorporated.  Let me know if I missed anything.  Thanks!

[Drew Kerman]

made it a little further along but I'm borked again. The last event I added hung up the script. I was able to save (should have been saving after each new event, dammit!) but now it won't finish loading. Case file. Also included is the "clean" version from after I setup my rocket and the Close button doesn't work for that vehicle still.