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

[Arrowstar]

Alright, I'm all set up on 0.90 but haven't had time to test any aerobraking, although I can now view the celestial body catalog with the latest pre-release so that's a good sign. At the moment I'm flying my 3-day kerbed Mun mission since I've been itching to see how this plays out for a few weeks now! So far so good, launched into a good orbit and re-optomized to get myself around Mun, after which I have plenty of coast time to re-sync my orbit to match the rest of the mission plan.

Used the RMS to get a new intercept with Mun after plugging in my actual orbital data from the game and the search window feature worked great.

However I did want to mention that, when re-optimizing a mission, the optimizer's Final State window could be extremely confusing to newbies. This is because I'm optimizing for event 5 but the Final State readout is showing me where I'll be at event 48. It would be nice to see the state of the craft in the event for which I am actually optimizing.

Noted. I'll think about how that could work, or if I want it to work that way. Yeah, good thought.

Let me know when you get to the aerobraking stuff.

---

In other news, some about some low thrust maneuver modeling?

[Drew Kerman]

In other news, some about some low thrust maneuver modeling?

I'm not entirely sure what's going on here but it appears that the first Dv maneuver is setting the throttle at like 25% and then the coast is modeling the trajectory of your ship as its orbit increases and then the second coast event is cutting the throttle? I'm a little confused as the colors on the orbital plot show more state changes than there are in the list

- - - Updated - - -

I have what is either an issue or me not doing things properly. I used UT to set the point of a burn to Mun, rather than coast to UT and then coast to True Anomaly. So from Initial State I coasted to UT and then have my Dv Maneuver (the UT and Dv values were taken from the RMS, with upper/lower bounds added so I could optimize). I set MA to give me a 941.8966km Pe around Mun and that's what it tells me I should get for the given UT (blue-boxed values). However when I upload the Dv Maneuver I don't get a Mun intercept, and I need to tweak the UT back a few seconds to get something close to what I desire (red-boxed values). I tested both with and without RSS to make sure that wasn't still causing problems.

Mission File

[diomedea]

Well, to me shows a low-thrust continuous burn, starting at stage 3 but ongoing for all of stage 4 (instead of an almost instant DV change as we had before) and the thrust is then changed to zero at stage 5 (unless stage 5 was just for circularization in a higher orbit). Seems a proof-of-concept for the ongoing thrust during a coast stage. The spiraling effect shown on the graph is nice, useful to make easily out what happens; but continuous-low-thrust is IMHO more important with deep space navigation or with orbital insertion/escape, raising an orbit is just one possibility. If I'm seeing this correctly, this is another of the many wonders KSPTOT MA will allow, looking forward at the possibilities .

[Arrowstar]

I have what is either an issue or me not doing things properly. I used UT to set the point of a burn to Mun, rather than coast to UT and then coast to True Anomaly. So from Initial State I coasted to UT and then have my Dv Maneuver (the UT and Dv values were taken from the RMS, with upper/lower bounds added so I could optimize). I set MA to give me a 941.8966km Pe around Mun and that's what it tells me I should get for the given UT (blue-boxed values). However when I upload the Dv Maneuver I don't get a Mun intercept, and I need to tweak the UT back a few seconds to get something close to what I desire (red-boxed values). I tested both with and without RSS to make sure that wasn't still causing problems.

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

Mission File

I'll take a look. I really suspect that I have a problem with the way that I compute the position of bodies compared to KSP. Sometimes it just doesn't seem like everything is in the place it should be. Out of curiosity, does anyone know if it's possible to get the position/velocity vectors for the planets and moons? That would be a simple way to check that I'm correct.

Gaiiden, is this problem something you might be able to help me pin down and fix?

Well, to me shows a low-thrust continuous burn, starting at stage 3 but ongoing for all of stage 4 (instead of an almost instant DV change as we had before) and the thrust is then changed to zero at stage 5 (unless stage 5 was just for circularization in a higher orbit). Seems a proof-of-concept for the ongoing thrust during a coast stage. The spiraling effect shown on the graph is nice, useful to make easily out what happens; but continuous-low-thrust is IMHO more important with deep space navigation or with orbital insertion/escape, raising an orbit is just one possibility. If I'm seeing this correctly, this is another of the many wonders KSPTOT MA will allow, looking forward at the possibilities .

Basically correct. The two dv maneuvers are of a new type called "finite duration." In this mode, the thrust is modeled as occurring over some finite period and not instantaneously. The first burn is very long, and the second is much shorter. Modeling is done with a numerical integrator and force models. You can use this for any thrust, by the way, it doesn't need to be "low thrust." Any other questions?

[Drew Kerman]

Gaiiden, is this problem something you might be able to help me pin down and fix?

Yea totally. I've played a bit more and here's additional problems on the issue:

This is after I gave MA the orbital data from an SFS file I saved right after performing my TMI burn, then I coasted to next SOI change (the event that's shown) and then coasted to Pe. What's odd is that in testing when I was hunting down the RSS issue I didn't see anything as off as this once I got things working again:

I'm going to strip down to stock and see what happens

Update mission file

[diomedea]

Basically correct. The two dv maneuvers are of a new type called "finite duration." In this mode, the thrust is modeled as occurring over some finite period and not instantaneously. The first burn is very long, and the second is much shorter. Modeling is done with a numerical integrator and force models. You can use this for any thrust, by the way, it doesn't need to be "low thrust." Any other questions?

Well, more a consideration of mine than a question, but you sure will shed more light about that.

One of the more critical low-thrust maneuvers I know is an orbital ejection. As it takes several hundred m/s in DV from a low orbit to eject (about 950 m/s from a 80 km altitude LKO), a craft with only a low-thrust engine may require a longer burn time than the acceptable arc at periapsis is travelled (e.g., in a 80 km circular LKO a craft orbits at 2279 m/s, if the acceptable arc was 20° it would be travelled in 104 seconds. Let me say that engine provides 1 m/s acceleration, that would require 9 subsequent "finite duration" thrusts at periapsis to achieve just the escape velocity, and then more for a Hohmann transfer to another planet) (actually more than 9, as the periapsis speed would increase at each orbit).

I'm looking forward at planning the "9 (or more) subsequent finite duration thrusts at periapsis" and seeing them nicely displayed on the MA graph . And, to export those maneuvers in KSP for execution... much easier than done manually.

[Drew Kerman]

ok Arrowstar (or anyone else that wants to try) I have identified the issue - I have no clue what it is but I have some reproduction steps for you.

required files

1. Start KSPTOT
   
2. Open Mission Architect
   
3. Open Initial State edit dialog and select to import from SFS
   
4. Open file "03-Coast to Mun.sfs"
   
5. First craft, Mun III, is at the top so just click Use Selected Orbit
   
6. Click Save & Close
   
7. Select Coast event to insert
   
8. Set Coast event to Go To Periapsis and select Mun for the Reference Body
   
9. Click Save & Close
   
10. Hover mouse cursor over Final Spacecraft State and note Periapsis Alt. = 941.4571
    
11. Click Open
    
12. Open mission file "Mun III - (2)Coast to Mun.mat"
    
13. Select Event 2 and right-click to select View State After Event
    
14. Hover mouse cursor over Final Spacecraft State and note Periapsis Alt. = 1391.575
    
15. Select New
    
16. Repeat steps 3-9
    
17. Hover mouse cursor over Final Spacecraft State and note Periapsis Alt. = 1391.575
    
18. Close MA
    
19. Repeat steps 2-9
    
20. Hover mouse cursor over Final Spacecraft State and note Periapsis Alt. = 941.4571
    

This is on the latest release version you made available for download.

So there's no error in KSP, there's initially no error in KSPTOT, but after I've loaded up that mission file something goes sideways. I've also included the previous step in the mission (1)LKO Orbit. If you open this file, select Event 5 and Advance Script To This Event, then load the orbital data from 03-Coast to Mun.sfs you will end up with what I have in the file (2)Coast to Mun

Edited January 19, 2015 by Gaiiden

[Arrowstar]

Gaiiden, can you also describe what's wrong based on the steps you've provided? Where should I be looking for the issue and what does the issue look like?

[Drew Kerman]

Gaiiden, can you also describe what's wrong based on the steps you've provided? Where should I be looking for the issue and what does the issue look like?

Reference the image in my post prior to the last one. You'll see that MA is giving me 1391.757km Pe when the game is showing 940.809km Pe. The steps I gave show you how to reproduce the issue and demonstrates that MA initially does give a correct Pe altitude

Oh, and I just realized my initial issue with the UT burn is a separate thing... I haven't spent any time investigating that yet.

[Drew Kerman]

Is it possible to get finer levels of zoom when viewing the orbit display in the popout window? Maybe not as default, but with holding down the Ctrl key. Better for framing things for images

[Arrowstar]

Reference the image in my post prior to the last one. You'll see that MA is giving me 1391.757km Pe when the game is showing 940.809km Pe. The steps I gave show you how to reproduce the issue and demonstrates that MA initially does give a correct Pe altitude

Oh, and I just realized my initial issue with the UT burn is a separate thing... I haven't spent any time investigating that yet.

I followed your instructions and did see a difference. After some investigation, I found that your celestial body data in the case you sent me ("Mun III - (2)Coast to Mun") does not match the celestial body data I have on hand for the Mun, Minmus, and Ike. Namely, their mean anomalies appear to be different.

Mun (my data ; your data ; difference)

mean: 97.4028 ; 115.6227 ; -18.2199

Minmus (my data ; your data ; difference)

mean: 89.5662 ; 338.1597 ; -248.5935

Ike(my data ; your data ; difference)

mean: 97.4028 ; 234.2584 ; -136.8556

Did you chance a bodies.ini file somewhere? Are your values correct, maybe? These are pretty big differences... I'd like to know where your values come from and if I need to change mine to match.

Is it possible to get finer levels of zoom when viewing the orbit display in the popout window? Maybe not as default, but with holding down the Ctrl key. Better for framing things for images

Actually, there's not much I can do there. That window is a built-in MATLAB figure window I just draw the image to. Can't adjust much of its underlying properties. Can you try using the little magnifying glasses and clicking-dragging to zoom that way?

- - - Updated - - -

Well, more a consideration of mine than a question, but you sure will shed more light about that.

One of the more critical low-thrust maneuvers I know is an orbital ejection. As it takes several hundred m/s in DV from a low orbit to eject (about 950 m/s from a 80 km altitude LKO), a craft with only a low-thrust engine may require a longer burn time than the acceptable arc at periapsis is travelled (e.g., in a 80 km circular LKO a craft orbits at 2279 m/s, if the acceptable arc was 20° it would be travelled in 104 seconds. Let me say that engine provides 1 m/s acceleration, that would require 9 subsequent "finite duration" thrusts at periapsis to achieve just the escape velocity, and then more for a Hohmann transfer to another planet) (actually more than 9, as the periapsis speed would increase at each orbit).

I'm looking forward at planning the "9 (or more) subsequent finite duration thrusts at periapsis" and seeing them nicely displayed on the MA graph . And, to export those maneuvers in KSP for execution... much easier than done manually.

So I guess I don't understand your question. Is there something you're looking for information about?

[Drew Kerman]

I followed your instructions and did see a difference. After some investigation, I found that your celestial body data in the case you sent me ("Mun III - (2)Coast to Mun") does not match the celestial body data I have on hand for the Mun, Minmus, and Ike.

Oh, derp. I see, I guess it was still using values from the bodies.ini changes I made to compensate for the RSS orbital period differences. I didn't realize that was all stored inside the .mat file. Ok, no big deal then! I don't actually need the mission file for the transfer to Mun - that's a straightforward thing. All the meaty stuff in the mission takes place around Mun and that shouldn't be affected by any of the changes I made to the bodies.ini file - except for the burn home, but again I can just do that as a separate thing. All good.

Actually, there's not much I can do there. That window is a built-in MATLAB figure window I just draw the image to. Can't adjust much of its underlying properties. Can you try using the little magnifying glasses and clicking-dragging to zoom that way?

Son of a... I was trying all kinds of things and I never thought of click dragging. Thanks!

[diomedea]

So I guess I don't understand your question. Is there something you're looking for information about?

Indeed, I did not even formulate a question . But you're right, I'm looking for more info about a capability I would like to see with KSPTOT MA.

Actually, what I described is the way I would manually plan a split-burn maneuver. Clearly that is only required for low-thrust continuous burns. It's a tedious process, though not terribly difficult, to do in KSP.

However, the duration of the whole maneuver can be relatively long (from first to the last of the burns, because those are executed on subsequent enlarging orbits), and therefore this maneuver must be started such amount of time earlier, or the subsequent transfer after escape will bring the craft where the target was that time earlier - probably an error enough to completely miss the intercept. Or, the transfer should account for that delay, therefore aiming since the escape to a different point in space.

Now, unless I missed something (very possible), I should be able to use MA to plan the single 9 (or more) burns required, tie them with the target intercept, optimize and have a solution ready to be used in KSP. But while MA would allow the precision I need, planning burns that way remains a tedious process. And I'm far from certain that I may be able to optimize the duration of each single burn that way.

Therefore I'd like if, with the "finite-duration" burns now possible (allowing to use low-thrust engined crafts), KSPTOT MA would also allow to directly plan the split-burn maneuvers (that said crafts will have to use). Would be nice if the user could just make a single entry in the event list and let MA create the single split burns as needed to achieve the final DV required.

[Drew Kerman]

minor UX beef - importing orbital data (from SFS at least) into the Other Spacecraft dialog does not update the Body selection. It does this with the Initial State box

oh and you know how I asked a while ago for the ability to "undo" changes to the graphical analysis charts? Maybe the program can auto-save the figure chart each time a new one is output, and revert button would just load the last auto-save (no need for a history). When the window is closed the temporary save file is deleted.

Edited January 20, 2015 by Gaiiden

[Drew Kerman]

Oh, derp. I see, I guess it was still using values from the bodies.ini changes I made to compensate for the RSS orbital period differences. I didn't realize that was all stored inside the .mat file. Ok, no big deal then! I don't actually need the mission file for the transfer to Mun - that's a straightforward thing. All the meaty stuff in the mission takes place around Mun and that shouldn't be affected by any of the changes I made to the bodies.ini file - except for the burn home, but again I can just do that as a separate thing. All good.

I take that back. Having reached Mun SOI and advancing my script to Coast to PE event and resetting the initial state with new orbital data, I find that MA is off from the game still. It gives me a circularize Dv maneuver for 941km but the game says my Ap will be 950 after I upload the maneuver. I also checked and my True Anomaly is nowhere near what the game is telling me.

Is there a way to reset the bodies data in the .mat file or will I just have to reconstruct the mission?

[immelman]

Hi there. I'd like to replicate the Voyager 2 mission in Real Solar System and would like to use KSPTOT to help me plan the burns.

Would someone have information on the orbital information I need to start on this, it looks like I need a "bodies" file for the Sol system?

[Drew Kerman]

so the RMS is now capable of giving me burns for intercepting a craft on a similar orbit at the exact Initial Epoch I tell it to:

This then begs the question - is it possible to further improve upon this ability by giving us the option to have it look ahead within the given Search Window Length for either the most dV efficient transfer or the most time efficient transfer? Maybe also a slider that you move towards one or the other if you'd like to spend a little more dV to get there faster, split it in half, etc. Right now I'm just plugging in different times to see what's best for either scenario.

Additionally, the RMS needs some sanity checking. It just gave me a rendezvous plot that takes me 25km down through Mun

Edited January 21, 2015 by Gaiiden

[diomedea]

Hi there. I'd like to replicate the Voyager 2 mission in Real Solar System and would like to use KSPTOT to help me plan the burns.

Would someone have information on the orbital information I need to start on this, it looks like I need a "bodies" file for the Sol system?

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

[Arrowstar]

minor UX beef - importing orbital data (from SFS at least) into the Other Spacecraft dialog does not update the Body selection. It does this with the Initial State box

Fixed in the development version. Thanks!

oh and you know how I asked a while ago for the ability to "undo" changes to the graphical analysis charts? Maybe the program can auto-save the figure chart each time a new one is output, and revert button would just load the last auto-save (no need for a history). When the window is closed the temporary save file is deleted.

I'll keep it in mind. This kind of thing is pretty low priority at the moment, I'll admit (mostly because it would involve during those plots into their own special GUI instead of letting MATLAB handle the plotting internally, which is what it does now and is way easier).

I take that back. Having reached Mun SOI and advancing my script to Coast to PE event and resetting the initial state with new orbital data, I find that MA is off from the game still. It gives me a circularize Dv maneuver for 941km but the game says my Ap will be 950 after I upload the maneuver. I also checked and my True Anomaly is nowhere near what the game is telling me.

Okay. Would you be up for helping me investigate why this is happening? It's seriously the one bug that has existed for some time (that I know of) and I can't seem to track it down or understand what's wrong. It must be something in either A) my bodies.ini file for stock KSP or an error with the way I'm doing the position/velocity vector conversion to Keplerian elements and back again. Would definitely appreciate help on this one!

Is there a way to reset the bodies data in the .mat file or will I just have to reconstruct the mission?

I can do it using MATLAB, but there's no way for you to do it yourself. I have to edit the save file manually. Or you can just redo the mission, yup.

so the RMS is now capable of giving me burns for intercepting a craft on a similar orbit at the exact Initial Epoch I tell it to:

http://i.imgur.com/0XP09kF.png

This then begs the question - is it possible to further improve upon this ability by giving us the option to have it look ahead within the given Search Window Length for either the most dV efficient transfer or the most time efficient transfer? Maybe also a slider that you move towards one or the other if you'd like to spend a little more dV to get there faster, split it in half, etc. Right now I'm just plugging in different times to see what's best for either scenario.

It could be done. How would you suggest that it gets implemented? In a phrase, how does the slider work?

Additionally, the RMS needs some sanity checking. It just gave me a rendezvous plot that takes me 25km down through Mun

I've added a simple constraint to make sure that Pe stays above radius + atmo and Ap stays below SoI radius. Good catch.

- - - Updated - - -

Indeed, I did not even formulate a question . But you're right, I'm looking for more info about a capability I would like to see with KSPTOT MA.

Actually, what I described is the way I would manually plan a split-burn maneuver. Clearly that is only required for low-thrust continuous burns. It's a tedious process, though not terribly difficult, to do in KSP.

However, the duration of the whole maneuver can be relatively long (from first to the last of the burns, because those are executed on subsequent enlarging orbits), and therefore this maneuver must be started such amount of time earlier, or the subsequent transfer after escape will bring the craft where the target was that time earlier - probably an error enough to completely miss the intercept. Or, the transfer should account for that delay, therefore aiming since the escape to a different point in space.

Now, unless I missed something (very possible), I should be able to use MA to plan the single 9 (or more) burns required, tie them with the target intercept, optimize and have a solution ready to be used in KSP. But while MA would allow the precision I need, planning burns that way remains a tedious process. And I'm far from certain that I may be able to optimize the duration of each single burn that way.

Therefore I'd like if, with the "finite-duration" burns now possible (allowing to use low-thrust engined crafts), KSPTOT MA would also allow to directly plan the split-burn maneuvers (that said crafts will have to use). Would be nice if the user could just make a single entry in the event list and let MA create the single split burns as needed to achieve the final DV required.

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

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

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

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

I haven't actually run this, but it sounds like a plausible place to start. How does that sound?

- - - Updated - - -

Hi there. I'd like to replicate the Voyager 2 mission in Real Solar System and would like to use KSPTOT to help me plan the burns.

Would someone have information on the orbital information I need to start on this, it looks like I need a "bodies" file for the Sol system?

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

http://pastebin.com/k9npkdKz

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

- - - Updated - - -

In other news! The third pre-release of v1.1.9 is ready to go for your viewing pleasure. See the following link for the ZIP file. As usual, no source code, just EXE, a new KSPTOTConnect.dll file, and the bodies.ini file.

KSPTOT v1.1.9 prerelease 3

[Drew Kerman]

I'll keep it in mind. This kind of thing is pretty low priority at the moment, I'll admit (mostly because it would involve during those plots into their own special GUI instead of letting MATLAB handle the plotting internally, which is what it does now and is way easier).

No don't bother making your own GUI. I can save/open the charts already with the current GUI but if you don't have access to do that via code then just forget about it.

Okay. Would you be up for helping me investigate why this is happening? It's seriously the one bug that has existed for some time (that I know of) and I can't seem to track it down or understand what's wrong. It must be something in either A) my bodies.ini file for stock KSP or an error with the way I'm doing the position/velocity vector conversion to Keplerian elements and back again. Would definitely appreciate help on this one!

This isn't an issue, I was just noting that the problem exists within the .mat file. I'm just rebuilding as I go, I can still use the old mission file to remember the overall plan.

It could be done. How would you suggest that it gets implemented? In a phrase, how does the slider work?

Burn Efficiency

Time <---------[]---------> ÃŽâ€v = you telling the RMS to find you a maneuver that neither takes too long or too much ÃŽâ€v (total)

Time <------------------[]> ÃŽâ€v = you telling the RMS you don't care how long it takes you to get there as long as the total ÃŽâ€v is as low as possible

Time <[]------------------> ÃŽâ€v = you telling the RMS you don't care how much total ÃŽâ€v you end up using, you want to get there as fast as possible

A generic use case for the slider would be

Time <---------[]---------> ÃŽâ€v (1) default setting

Time <-------------[]-----> ÃŽâ€v (2) after getting a result on the default setting, you decide you want to spend a little less ÃŽâ€v to get there

Time <-----------[]-------> ÃŽâ€v (3) oops, now it's taking a bit too long. This should be good.

the Search Window setting would be used to tweak the granularity of the slider. If you search over a larger period you're going to get a greater gap between burn results. For example:

Search Window 1000s

Time <---------[]---------> ÃŽâ€v = 1.2km/s 9h:10m

Time <-------------[]-----> ÃŽâ€v = 0.7km/s 10h:44m

Search Window 100s

Time <---------[]---------> ÃŽâ€v = 1.2km/s 9h:10m

Time <-------------[]-----> ÃŽâ€v = 0.9km/s 9h:36m

[Arrowstar]

This isn't an issue, I was just noting that the problem exists within the .mat file. I'm just rebuilding as I go, I can still use the old mission file to remember the overall plan.

Okay. So in your opinion, the bodies.ini file I have accurately represents the stock KSP solar system?

Burn Efficiency

Time <---------[]---------> ÃŽâ€v = you telling the RMS to find you a maneuver that neither takes too long or too much ÃŽâ€v (total)

Time <------------------[]> ÃŽâ€v = you telling the RMS you don't care how long it takes you to get there as long as the total ÃŽâ€v is as low as possible

Time <[]------------------> ÃŽâ€v = you telling the RMS you don't care how much total ÃŽâ€v you end up using, you want to get there as fast as possible

A generic use case for the slider would be

Time <---------[]---------> ÃŽâ€v (1) default setting

Time <-------------[]-----> ÃŽâ€v (2) after getting a result on the default setting, you decide you want to spend a little less ÃŽâ€v to get there

Time <-----------[]-------> ÃŽâ€v (3) oops, now it's taking a bit too long. This should be good.

the Search Window setting would be used to tweak the granularity of the slider. If you search over a larger period you're going to get a greater gap between burn results. For example:

Search Window 1000s

Time <---------[]---------> ÃŽâ€v = 1.2km/s 9h:10m

Time <-------------[]-----> ÃŽâ€v = 0.7km/s 10h:44m

Search Window 100s

Time <---------[]---------> ÃŽâ€v = 1.2km/s 9h:10m

Time <-------------[]-----> ÃŽâ€v = 0.9km/s 9h:36m

Okay. So are there two sliders (Burn Efficiency & Search Window) or is it just the one?

[Drew Kerman]

Okay. So in your opinion, the bodies.ini file I have accurately represents the stock KSP solar system?

My Mun mission plotting as I progress through it has been fine so long as I don't ever load that .mat file with the bad bodies info I cooked up when I was hunting down that RSS issue. I can't speak for the whole Kerbol system.

Okay. So are there two sliders (Burn Efficiency & Search Window) or is it just the one?

One slider - the Search Window refers to the existing field already in the RMS where you just enter in the seconds to determine the breadth of the search

[diomedea]

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

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

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

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

I haven't actually run this, but it sounds like a plausible place to start. How does that sound?

Sure some good advice in that. You got what I mean, N finite maneuvers to provide a total DV as planned for a single impulsive burn. Though, time taken to execute those N maneuvers must be considered, or the resulting trajectory will miss the target.

Of course I'd much prefer if an automated solution was possible, even if that required optimization in steps. While relatively simple, manual splitting burns requires some computation about the max DV achievable with each burn. That means going in that tedious repetitive process (determine time to travel the elliptical arc at periapsis; determine DV achieved during that finite time; update orbital params; repeat until total achievable DV >= required DV), unless KSPTOT MA optimization is enough to correct wild estimates a user may provide about the DV at each burn. I'll go with the first approach and a spreadsheet.

However one optimization I see MA should be used for is about the total time required for the maneuver. I mean, if I strive for maximum distance at apoapsis, I'll just get the burn going for as long as possible within the acceptable arc, can't see a reason why MA shouldn't; but it shouldn't if the result is to bring the craft on a very eccentric orbit at the N-1 burn, and have a long time to travel that orbit just to perform a smaller final burn at the Nth burn: a better solution would be to optimize duration in reverse, applying the longer possible burns at the Nth step and going down, so to result in lower orbits before and a lower total time.

Then, I think I may have a problem. You made a good example telling total DV for getting in the transfer orbit = 2000 m/s. However, after I burned 950 m/s my craft is already about to leave Kerbin's SoI, therefore no more periapsis passages. That means my craft will have to keep burning while on the outgoing leg from Kerbin to provide the remaining 1050 m/s. But what direction? For efficiency, I want it already aimed so to only need a prograde burn. And this is where really I need MA to optimize, it should choose the timing of the previous burns so that the ejection vector is aligned for that final burn to get the craft on the transfer route. Now, how better to give conditions to MA for this kind of optimization? The final direction solution reverberates back with all the previous burns until each one timing and vector are optimized, so I can't think optimizing a single stage at a time could be effective.

Well, you told something's hard about this problem. Doesn't seem to me it belongs to the NP-complete class, however it may require more than the usual computational power to solve, possibly some extensive parallel computing. Doable within the limits of MA routines?

[Arrowstar]

The fourth pre-release of v1.1.9 is ready to go for your viewing pleasure. See the following link for the ZIP file. As usual, no source code, just EXE, a new KSPTOTConnect.dll file, and the bodies.ini file.

New features include a delta-v budget tool and a launch window analysis tool in Mission Architect. See the Tools menu in MA.

KSPTOT v1.1.9 prerelease 4

I will get to answering posts above when I can.

[Arrowstar]

Sure some good advice in that. You got what I mean, N finite maneuvers to provide a total DV as planned for a single impulsive burn. Though, time taken to execute those N maneuvers must be considered, or the resulting trajectory will miss the target.

Of course I'd much prefer if an automated solution was possible, even if that required optimization in steps. While relatively simple, manual splitting burns requires some computation about the max DV achievable with each burn. That means going in that tedious repetitive process (determine time to travel the elliptical arc at periapsis; determine DV achieved during that finite time; update orbital params; repeat until total achievable DV >= required DV), unless KSPTOT MA optimization is enough to correct wild estimates a user may provide about the DV at each burn. I'll go with the first approach and a spreadsheet.

However one optimization I see MA should be used for is about the total time required for the maneuver. I mean, if I strive for maximum distance at apoapsis, I'll just get the burn going for as long as possible within the acceptable arc, can't see a reason why MA shouldn't; but it shouldn't if the result is to bring the craft on a very eccentric orbit at the N-1 burn, and have a long time to travel that orbit just to perform a smaller final burn at the Nth burn: a better solution would be to optimize duration in reverse, applying the longer possible burns at the Nth step and going down, so to result in lower orbits before and a lower total time.

Then, I think I may have a problem. You made a good example telling total DV for getting in the transfer orbit = 2000 m/s. However, after I burned 950 m/s my craft is already about to leave Kerbin's SoI, therefore no more periapsis passages. That means my craft will have to keep burning while on the outgoing leg from Kerbin to provide the remaining 1050 m/s. But what direction? For efficiency, I want it already aimed so to only need a prograde burn. And this is where really I need MA to optimize, it should choose the timing of the previous burns so that the ejection vector is aligned for that final burn to get the craft on the transfer route. Now, how better to give conditions to MA for this kind of optimization? The final direction solution reverberates back with all the previous burns until each one timing and vector are optimized, so I can't think optimizing a single stage at a time could be effective.

Well, you told something's hard about this problem. Doesn't seem to me it belongs to the NP-complete class, however it may require more than the usual computational power to solve, possibly some extensive parallel computing. Doable within the limits of MA routines?

So the new finite duration maneuver has a "steered" mode which always points in the same prograde-normal-radial direction throughout the burn. It's called steered because as you burn, the prograde vector is constantly recomputed and the thrust directed along that new vector. Using something like this, you might be able to collapse your 9 burns down into 2 or 3.

The problem with nine burns is that it's genuinely hard to optimize. That's a lot of variables! You as the analyst need to impose some structure on the problem, which I've done in my example (of course, it might not be the best structure, but you get the idea!). Otherwise, free form optimization way not yield very good results.

Before we continue on, I'd encourage you to try to model what you're doing in the latest pre-release and see how well it works. (Btw: the optimizer in MA got an overhaul and I think it performs somewhat better now.) One you've tried that, let's talk about specific things we could do to improve it.

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