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

[SpacedInvader]

So, all the split maneuver tool does is take the delta-v unit vector of the burn you want to split and multiple it by the various delta-v magnitudes that come out of the tool. I believe it spaces the burns by the orbital periods between burns.

I admit I didn't really understand the problem you were trying to describe. Could you maybe show me with some pictures or something?

Ok, here's what I'm trying to describe:

Original Maneuver

Split Settings

Maneuver 1

Maneuver 2

As you can see, the dV Vector settings are identical for both maneuvers, but the optimizer constraints, which indicate what the vectors are actually supposed to be, are different. I have attempted to manually adjust the set dV vectors for the second maneuver to match those described by the optimizer constraints, but they do not save correctly. Forcing me to copy down the desired settings and then delete the second node and recreate it manually.

On that note, since all the tool does is split the maneuver and doesn't take account the timing / true anomaly of the final burn, what would be the steps necessary to set up a multi-burn maneuver like this where the final burn (i.e. the one that finally sends me out of the SoI) is timed / lined up correctly to give me the most efficient final orbit?

[Arrowstar]

Okay, got it. Can I get the MAT file with that initial event in it?

[SpacedInvader]

Okay, got it. Can I get the MAT file with that initial event in it?

Here you go, I would really like your input on my last question there when you get a chance, as I would like to be able to properly plan multi-part maneuvers without having the end result be less efficient because the timing is wrong.

[Drew Kerman]

Btw, can you try this build out and see if it resolves the animator issue with Other Spacecraft? I think I got it to stop freezing, but the performance may not still be great. Please let me know. This is a really deep bug, probably has some roots in MATLAB's internal plotting code itself.

Sorry, no joy. I get no craft orbits at all with the Minmus file but I loaded another file with more craft than the Minmus one (around Kerbin) and they showed up fine. I stopped testing though when I realized the lack of animation when pressing the play button could be recreated from a stock mission file. Load up Mission Architect, set a TA Coast for 1 rev, open the Mission Animator and press play. Nothing happens. Log has this (I clicked the button a few times):

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 8)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 34)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 8)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 34)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 8)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 34)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 8)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Undefined function 'profile' for input arguments of type 'char'.

Error in ma_handlePlayButton (line 34)



Error in ma_MissionAnimatorGUI>playButton_Callback (line 240)



Error in gui_mainfcn (line 95)



Error in ma_MissionAnimatorGUI (line 42)



Error in @(hObject,eventdata)ma_MissionAnimatorGUI('playButton_Callback',hObject,eventdata,guidata(hObject))


Error while evaluating UIControl Callback

Error writing to output stream.

Also, was my response to SpacedInvader at all accurate/helpful?

[SpacedInvader]

Also, was my response to SpacedInvader at all accurate/helpful?

It did help some. I think the biggest problem I've got right now is that I don't have a decent background knowledge of orbital mechanics... Up to this point, my missions been a lot of me telling MechJeb where I want to go, and then MechJeb making it happen. That works just fine for short duration missions where dV is relatively cheap, but not so much when going far out into the Kerbol system with a list of mission objectives as long as your arm. After all, if a mission needs 1k dV and you bring 2k, you've just massively increased the size of your launch vehicle for no reason. As a result of this lack of background, I'm having difficulty using TOT correctly. For example, I only barely know what True Anomaly is, and now I'm suddenly trying to define it as a variable to work with in creating a proper flight plan. I think with time and practice I'll be able to get the hang of it.

[Drew Kerman]

I think with time and practice I'll be able to get the hang of it.

Sure. Worked for me

[Arrowstar]

Sorry, no joy. I get no craft orbits at all with the Minmus file but I loaded another file with more craft than the Minmus one (around Kerbin) and they showed up fine. I stopped testing though when I realized the lack of animation when pressing the play button could be recreated from a stock mission file. Load up Mission Architect, set a TA Coast for 1 rev, open the Mission Animator and press play. Nothing happens. Log has this (I clicked the button a few times):

Huh, I guess you can't leave logging code in or it throws an error. Did not know that.

Can you try this build? I removed the offending function calls.

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v131_prerelease4.zip

[SpacedInvader]

So how would I got about planning out a trip to the mun or minmus from kerbin? So far in trying to plan a mission to minmus, I've resorted to allowing for 360° freedom on the coast to true anomaly optimization, but as of yet, this hasn't resulted in an encounter with the SoI. Is there a better way to do this?

[Drew Kerman]

Can you try this build? I removed the offending function calls.

Quick test worked great, excellent job! I tried it on the original problem MAT file of Minmus and also one of Kerbin surrounded by satellites. No animation issues, played around with the controls a bit. One minor thing I noticed that seemed a bit odd was this:

Click for the full size, and note the Scale Factor is all the way out. The yellow outer orbit doesn't show a vessel until I move back to 1546km Range Offset, which makes everything smaller than it needs to be as opposed to the first settings which brings the yellow orbit more fully into the camera's view. Again, not a huge issue & possibly not a real issue - just something I noticed.

So how would I got about planning out a trip to the mun or minmus from kerbin? So far in trying to plan a mission to minmus, I've resorted to allowing for 360° freedom on the coast to true anomaly optimization, but as of yet, this hasn't resulted in an encounter with the SoI. Is there a better way to do this?

Ok we'll go for Minmus since if I give you instructions for Mun I would have to add a few steps anyways if you then asked for Minmus. Everything you do for Minmus works for Mun.

If you haven't launched yet:

(if you have, skip to 6)

1) Get your launch time - go to Mission Architect and select Tools->Launch Window Analysis.

2) Enter in Minmus' orbit information for the Target fields (I leave this exercise to you - check the Tools->Celestial Body Catalog)

3) Fill out the launch window parameters. Right-click the Window Search Start text box to enter in a time, or if you are in the flight scene import it from KSP. This time isn't when you want to launch, it's when you want to begin looking for when to launch. Really just enter in whatever current time is in the game. You can leave the Num. Revolutions field at default.

4) Click "Start Launch Window Analysis" and you'll get a list of UT times and azimuth headings. Less than 90 degress is a northern launch, greater than 90 degrees is a southern launch, hopefully that makes sense. You can copy the UT times and paste them in one of the UTC fields of the main KSPTOT window (Earliest Departure Time or Earliest Arrival Time) to convert the seconds into days, hours, mins, etc. Pick whatever time works best for you. NOTE: There is a potential issue with Minmus launch windows. Arrowstar is looking into it.

5) Launch at the appropriate time and incline your orbit to 6 degrees North or South of the equator (depending on which azimuth the Launch Window Analysis gave you for that time) while you ascend into orbit. This will simply save you the trouble of having to deal with any inclination changes burning from LKO to Minmus - it doesn't make the intercept plotting any easier or harder but can save you some fuel depending on how you want to arrive at Minmus, and how long you want to wait for a good Minmus transfer orbit

If you already have a craft in orbit:

6) Open Mission Architect and import you craft orbit from KSP or SFS file. It should be in a circular low-kerbin orbit like 75km to take as much advantage of the Oberth Effect as possible when burning for Minmus transfer. Technically you can be safe at 70km but I like to take it up a teeny bit higher.

7) After importing but before closing the Edit State window, right-click and copy the orbital parameters to the clipboard.

8) Save the state and then go back to the main KSPTOT window and select Tools->Maneuver Planning->Rendezvous Maneuver Sequencer.

9) Paste the craft orbital data into the Initial Orbit Info section.

10) Use the selection box in the Final (Desired) Orbit Info to load up Minmus' orbital properties.

11) Either copy the Epoch of the Initial Orbit Info section and paste that into the Search Initial Epoch section, or enter in a later time from which point forward (not necessarily that exact time) you want to find a transfer orbit to Minmus.

21) Hit the Compute Rendezvous Maneuvers button and wait. While we wait, note that I suggest leaving the Search Window Length alone, if you don't find a good result in the default time-span just adjust forward your Search Initial Epoch time by 2hrs and try again. I'm also not going to cover the Search Parameter Weightings, but the basic idea is do you want to find the most efficient route that saves you fuel (DV) or time (TOD)? You can balance that as you want/need but for this example we're going to take the most efficient fuel route (default setting) and not care how long it takes us to get there.

22) Okay by now you have a plotted result. The DV Maneuver 1 Information box (middle one on the right) is the data you're looking for. Check your departure and arrival UTC times by copy/pasting them into the main KSPTOT window and if they agree with you, copy the entire text of the window to an external text editor (otherwise you can't copy/paste from the RMS window into the Edit State windows in Mission Architect). If not, you can either advance your Initial Search Epoch by two hours or just re-run the sequencer with the same values and you could end up with a slightly different better/worse result (make sure you save the first result, cause it will be unrecoverable). The first result usually is fine.

23) Head back to Mission Architect and create a new Coast event. Select Go to UT and paste the Burn UT value from the text you copied from the RMS into the Universal Time text field. Be sure to uncheck the Opt box for now since the UT value will be outside the default entered range. Save the event.

24) Now re-open the event and change the type from Go to UT to Go to True Anomaly. This will convert the UT value to degrees and also give you a proper Revs Prior to Coast value. You can now re-check the Opt box as the values are back in range. Why not just leave it at UT? Way easier to optimize for TA - only 0-360 as opposed to coming up with the UT values for however many seconds, minutes, hours before and after the burn time. Why not just enter Burn True Anomaly from the RMS results? Because it doesn't take into account how many revolutions the craft may have taken in orbit from the Initial Orbit Info epoch to the time of the burn.

25) Now then, we create a Delta-V Maneuver event after our coast event. Use the RMS results to enter in the DV values for Prograde, Normal and Radial. Take care to make sure the proper values go in the proper field (I've accidentally used the Total DV RMS result for the Prograde box before). Save the event.

26) Finally, create a Coast event with Go to Periapsis and set the Reference Body to Minmus. Save the event.

27) If everything went well, you should now be impacting Minmus. Yay! Wait, no not yay. But from here you can use the Mission Optimizer to raise your Periapsis to something more reasonable for orbital capture after you arrive, as well as whatever else your mission parameters define. Since I don't know them, I can't offer any further advice. But any questions/problems just let me know.

Edited May 9, 2015 by Gaiiden

[Arrowstar]

So how would I got about planning out a trip to the mun or minmus from kerbin? So far in trying to plan a mission to minmus, I've resorted to allowing for 360° freedom on the coast to true anomaly optimization, but as of yet, this hasn't resulted in an encounter with the SoI. Is there a better way to do this?

It should be pretty easy, actually, to get Mission Architect to give you a coast to the Mun. Try these steps:

1. Create a Coast to 180 degrees True Anomaly. Set the bounds to 0 and 360 degrees.
   
2. Create a delta-v maneuver. Set the prograde DV to 800 m/s and the upper and lower bounds to 600 and 1000 m/s. Uncheck the normal and radial components, leave their DV at 0.
   
3. Create a coast to periapse. Set the coast's body to Mun.
   
4. Use Control-O to open the optimizer.
   
5. Change the optimization event to the final coast and the objective function to Minimize Distance to Body. Set the Body to Mun.
   
6. Leave constraints empty. Push the optimize button.
   
7. Wait. Go get coffee or something.
   
8. Come back and see your optimization has ended and your orbit now takes you to the Mun's SoI.
   

Let me know how this works for you.

EDIT: Ninja'd by Gaiiden and he did a better job. Listen to him, I wrote this 2 minutes before going to bed lol.

[Arrowstar]

Quick test worked great, excellent job! I tried it on the original problem MAT file of Minmus and also one of Kerbin surrounded by satellites. No animation issues, played around with the controls a bit. One minor thing I noticed that seemed a bit odd was this:

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

Click for the full size, and note the Scale Factor is all the way out. The yellow outer orbit doesn't show a vessel until I move back to 1546km Range Offset, which makes everything smaller than it needs to be as opposed to the first settings which brings the yellow orbit more fully into the camera's view. Again, not a huge issue & possibly not a real issue - just something I noticed.

Can I see the MAT file this occurs in? I'll take a look.

6) Open Mission Architect and import you craft orbit from KSP or SFS file. It should be in a circular low-kerbin orbit like 75km to take as much advantage of the Oberth Effect as possible when burning for Minmus transfer. Technically you can be safe at 70km but I like to take it up a teeny bit higher.

Thanks for the good instructions, Gaiiden! I need to clarify one point on this instruction, though. Often times, you do not want to have a low orbit. Remember that the Oberth Effect only applies if your burn vector is along your velocity vector. When you're very low, you subtend arcs more quickly and therefore your "maximum length" burn duration decreases. In fact, I would bet I could demonstrate that arc losses from burning off of your velocity vector as you go around in your low orbit are actually non-trivially greater than the losses you pick up from burning in a higher orbit (and thus with a slower velocity). Or maybe I'll just leave it as an exercise to the reader. My point is that you can't always just say "lower == better" when it comes to burn altitudes. You need to consider burn duration and how much of your delta-v is actually going into the radial component of your velocity vector integrated over the burn arc.

Btw, I'm investigating the Minmus launch window issue today. Can you confirm you're on the stock bodies.ini file?

- - - Updated - - -

Alright, so I did some testing within KSP and I couldn't reproduce the Minmus issue. My launch directions match the times. Here's what's the launch situation looks like for north and south launches. Can you try to match these results on your end?

 Lnch Wnd Ctr [UT sec] | Lnch Az. [deg] 
----------------------------------------
       3695.987        |    84.001     
       14612.975       |    95.999     
       25295.899       |    84.001     
       36212.887       |    95.999     
       46895.811       |    84.001     
       57812.799       |    95.999     
       68495.723       |    84.001     
       79412.711       |    95.999     
       90095.635       |    84.001     
      101012.623       |    95.999     
      111695.547       |    84.001     
      122612.535       |    95.999     
      133295.459       |    84.001     
      144212.447       |    95.999     
      154895.371       |    84.001     
      165812.359       |    95.999     
      176495.283       |    84.001     
      187412.271       |    95.999     
      198095.195       |    84.001     
      209012.183       |    95.999     
----------------------------------------

North Azimuth:

South Azimuth:

[SpacedInvader]

Wow, that's a pretty complicated process to hit a relatively easy orbital body! I'll give it a few tries to see what I can get out of it. If I can get it down decently, my next mission objective is to try a Mun gravity assist on the way to Duna since I have an unmanned Mun flyby mission that I can't delete even though I've already put Kerbals up there...

[Drew Kerman]

Can I see the MAT file this occurs in? I'll take a look.

Sure, same file as before but updated a bit - clicky

Thanks for the good instructions, Gaiiden! I need to clarify one point on this instruction, though. Often times, you do not want to have a low orbit. Remember that the Oberth Effect only applies if your burn vector is along your velocity vector. When you're very low, you subtend arcs more quickly and therefore your "maximum length" burn duration decreases. In fact, I would bet I could demonstrate that arc losses from burning off of your velocity vector as you go around in your low orbit are actually non-trivially greater than the losses you pick up from burning in a higher orbit (and thus with a slower velocity). Or maybe I'll just leave it as an exercise to the reader. My point is that you can't always just say "lower == better" when it comes to burn altitudes. You need to consider burn duration and how much of your delta-v is actually going into the radial component of your velocity vector integrated over the burn arc.

Ok, took me a bit to really comprehend that but I think I understand. I'm picturing it in my head like this:

Both red lines are the same burn length, but since the higher orbit is slower you don't travel as much along the arc and thus you have a "flatter" burn.

Btw, I'm investigating the Minmus launch window issue today. Can you confirm you're on the stock bodies.ini file?

Ok I did some investigation again too and found that I couldn't reproduce my earlier results. See the original image I posted and compare with this one:

Maybe it was an issue with the bodies.ini file I was using? I dunno. I'm positive I never ever messed with Minmus' orbital properties. I did generate a bodies.ini file with extra planets from some planet packs but I just checked it again the stock file and the Minmus properties match exactly so using one or the other shouldn't have made a difference. I will let you know if this ever pops up again but it appears "fixed".

Wow, that's a pretty complicated process to hit a relatively easy orbital body! I'll give it a few tries to see what I can get out of it. If I can get it down decently, my next mission objective is to try a Mun gravity assist on the way to Duna since I have an unmanned Mun flyby mission that I can't delete even though I've already put Kerbals up there...

The specific method Arrowstar gave you will work too if you think that's simpler, and it is because it's more direct to what you want. However the method I gave you also teaches you launch window calculation and basic rendezvous maneuver sequencing that you can now apply to a myriad of mission objectives. So don't just think of it as a way to get to Mun or Minmus!

[Arrowstar]

Thanks for checking out the launch window Minmus issue. Sounds good to call it resolved for now.

---

So I think I actually found a rare bug in my Kepler -> Position, Velocity function. I think this is what was causing me to need to use a different set of elements for Minmus instead of what comes out of the game itself. (I was using Arg = 0 and Mean = 89.xyz instead of the numbers on the KSP Wiki.) I believe I have fixed the issue in this new build though. Gaiiden, can you try this build and see if you run into anything? I had to generate some new compiled versions of my low level astrodynamics functions, so I'd be curious to hear about any problems you run into. Everything worked well over here...

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v131_prerelease5.zip

Note that I also updated the bodies.ini file with some atmospheric numbers and tweaked the GMs of most bodies to match what KSPTOTConnect gives me. The new KSPTOTConnect.dll also fixes a bug with generating bodies.ini files.

[Drew Kerman]

Cool, I snagged the new release but won't be able to give you any good feedback for a while as I'm currently working through my 0.90 -> 1.0.2 game save transition. Then I'm also backed off on my playing for a few weeks to recharge and rebuild my lead time on twitter. But anything I happen across I'll let you know straight away

[Arrowstar]

No worries. I think I'm just about ready for a real release tomorrow anyway.

[SpacedInvader]

So I've been trying to set up this Munar flyby / gravity assist for my Duna probe. I'm easily able to get the encounter using the steps described before, but the optimizer refuses to give me a 0° inclination encounter, instead always returning a 180° inclination, no matter what way I try to restrict the inclination to 0°. Is there a trick to this that I'm missing?

[Drew Kerman]

So I've been trying to set up this Munar flyby / gravity assist for my Duna probe. I'm easily able to get the encounter using the steps described before, but the optimizer refuses to give me a 0° inclination encounter, instead always returning a 180° inclination, no matter what way I try to restrict the inclination to 0°. Is there a trick to this that I'm missing?

Yea that's an easy fix - revert back to where you were smacking dead on into the planet from the RMS plot. Just go and manually tweak the Prograde DV value back a few m/s. That will move your orbit back outside the planet and give you an inclination close to 0 from which you can work back to 0 and adjust your Pe with the optimizer. If you tweak your Prograde forwards a few m/s, you'll find yourself at a 180 degree inclination. The problem you need to recognize here is that "minimize inclination" to the optimizer doesn't mean "reduce to 0" - 180 degrees of inclination is also an equatorial orbit - but in retrograde. So since both 0 and 180 degrees are equatorial orbits, just going in different directions, both states are "minimized" as far as the optimizer is concerned because you're not at any angle to the ecliptic plane. Getting your craft moving in the right direction first is the key

[Arrowstar]

The problem you need to recognize here is that "minimize inclination" to the optimizer doesn't mean "reduce to 0"

Actually, believe it or not, it does. The optimizer does try to find the minimum absolute value of inclination using that objective function, which in this case does mean 0 degrees. Use "maximize inclination to get it to go 180 degrees."

[Arrowstar]

Hi everyone,

I'm happy to announcement the release of KSP Trajectory Optimization Tool v1.3.1! This is primarily a bug fix release that addresses the following issues:

• Resolved an issue with axis scale in Mission Animator cutting off orbits;
  
• Resolved a few issues with KSPTOTConnect plugin that prevented a bodies.ini file from being generated correctly;
  
• Updated bodies.ini file to use GM values and atmospheric values from KSP v1.0.x;
  
• Resolved an issue with the Keplerian -> Vector elements conversion subroutine that caused an issue when eccentricity was 0.0 and inclination was greater than 0.0.
  
• One or two other minor bug fixes and tweaks.
  

As usual, please let me know if you find any issues or problems! Thanks!

Edited May 10, 2015 by Arrowstar

[diomedea]

Great, thanks for the new release .

(I'm more or less following, don't have enough time yet to keep on par with you and Gaiiden, but sure want to try the new version).

[Drew Kerman]

Actually, believe it or not, it does. The optimizer does try to find the minimum absolute value of inclination using that objective function, which in this case does mean 0 degrees. Use "maximize inclination to get it to go 180 degrees."

I stand corrected. My view of this comes from the same issue that SpacedInvader is facing, I was unable to figure out how to get the optimizer to "unstick" from 180 degrees after using the RMS to plot a course straight into the target body. I always had to back off a bit in the right direction first. I'm not saying the optimizer is incapable if doing this, I just couldn't figure out how to tell it to do this Regardless, it's not a huge problem to work around, one or two guesses in DV reduction does the trick nicely

[SpacedInvader]

Considering the changes to the bodies.ini file, is the new version compatible with KSP 0.90? I'm one who waits until all my favorite mods are compatible with the new version before updating and some of my most important ones seem like they won't be ready for a little while yet...

[Arrowstar]

Yes, it should be fine with 0.90. All the updates were very minor, usually just in the 6-8 decimal place.

[SpacedInvader]

The newest version of KSPTOTConnect doesn't appear to work with KSP 0.90. When trying to create a new bodies.ini, I get an error asking if KSP is running with the plugin activated and then KSP freezes.