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

[Drew Kerman]

1 hour ago, stankwoo said:

In the mission example that is included to show how to play Kerbin to Mun and back, there is a coast that is set as "SOI transition" after the DV maneuver. That is what I was trying to understand how it worked. 

it's pretty straight-forward. It propagates the orbit out to the point where the craft leaves the current SOI. It's similar to telling it to coast to descending node - you could also use a specific state like coast to true anomaly or coast to UT to get to the descending node on the trajectory, but any changes before that state and you would no longer be exactly at the descending node anymore. Coast to next SOI means that no matter what changes you make to the states beforehand it will always propagate into the next SOI or helpfully warn you if it can't

[stankwoo]

I really appreciate the explanation. 
 

On the example mission plan it basically looks like:

1. Coast to a certain true anomaly 

2. DV maneuver 

3. Coast to SOI

4. Coast to Kerbin PE

For the optimization, there is a constraint on step 3 above: central body ID of Kerbin and Kerbin Pe altitude of 0,0. 

I am guessing the optimization would be set to step 3 and then "Minimize distance to body" with "Kerbin" as the body. Since it is on step 3, it will be optimizing step 1 and step 2 above with trying to get the result within the constraints (re entering into Kerbin). Is this the correct explanation?

I will try this again tonight. My problem was I was getting a Pe altitude of 0 or close to it but my Ap was infinity. When I would upload it to KSP just to check, it showed me escaping the Mun but then also escaping Kerbin with a giant Pe. Basically not at all what the mission architect was telling me the final orbit was. That is the part I was having trouble on - using MechJeb maneuver it came up with was a Pe to re enter atmosphere and a Ap that was far away but not infinity. I'm not trying to leverage one tool against the other - just using both to learn what I am misunderstanding. (I'm positive the issue is between the seat and keyboard!)

Thanks again for the help, this has been a great learning experience. 

[Arrowstar]

3 hours ago, stankwoo said:

I really appreciate the explanation. 
 

On the example mission plan it basically looks like:

1. Coast to a certain true anomaly 

2. DV maneuver 

3. Coast to SOI

4. Coast to Kerbin PE

For the optimization, there is a constraint on step 3 above: central body ID of Kerbin and Kerbin Pe altitude of 0,0. 

I am guessing the optimization would be set to step 3 and then "Minimize distance to body" with "Kerbin" as the body. Since it is on step 3, it will be optimizing step 1 and step 2 above with trying to get the result within the constraints (re entering into Kerbin). Is this the correct explanation?

I will try this again tonight. My problem was I was getting a Pe altitude of 0 or close to it but my Ap was infinity. When I would upload it to KSP just to check, it showed me escaping the Mun but then also escaping Kerbin with a giant Pe. Basically not at all what the mission architect was telling me the final orbit was. That is the part I was having trouble on - using MechJeb maneuver it came up with was a Pe to re enter atmosphere and a Ap that was far away but not infinity. I'm not trying to leverage one tool against the other - just using both to learn what I am misunderstanding. (I'm positive the issue is between the seat and keyboard!)

Thanks again for the help, this has been a great learning experience. 

Could you please post the Mission Architect MAT file you're working on so I can take a look?  Thanks!

[stankwoo]

Sorry, forgot to attach link earlier - here it is: MAT file

[Arrowstar]

2 hours ago, stankwoo said:

Sorry, forgot to attach link earlier - here it is: MAT file

Here you go.  All I had to do was change the objective function to Maximize Spacecraft Mass and reoptimize.  It snapped right in, so I'm not sure what the issue was, but it seems to have been solved!

EDIT: Also I found a bug in MA after optimizing that is definitely in the v1.6.5 pre-releases and causes the program to crash.  I'll put out a new pre-release tomorrow with it fixed.

Edited January 21, 2020 by Arrowstar

[stankwoo]

Thanks!

I was using "Minimize distance to body" similar to how the tutorial does it. I figured I would use it from the Mun to Kerbin to get as close as possible. The big difference I see is when going from Kerbin to the Mun the objective function is "minimize distance to body" and the stage is a coast to the Pe after the DV maneuver for trans Mun injection. I was trying to optimize using the same objective function but on a stage coast to SOI. Not sure if that makes a difference. 

Is there a way I can understand why it was having a hard time using "minimize distance to body"? Or is that something you just learn over time to try different objective functions? My goal was to understand the results of the optimizer so I could know where to tweak as necessary.

Appreciate the patience while I attempt to harness the power!

[Arrowstar]

21 hours ago, stankwoo said:

Thanks!

I was using "Minimize distance to body" similar to how the tutorial does it. I figured I would use it from the Mun to Kerbin to get as close as possible. The big difference I see is when going from Kerbin to the Mun the objective function is "minimize distance to body" and the stage is a coast to the Pe after the DV maneuver for trans Mun injection. I was trying to optimize using the same objective function but on a stage coast to SOI. Not sure if that makes a difference. 

Is there a way I can understand why it was having a hard time using "minimize distance to body"? Or is that something you just learn over time to try different objective functions? My goal was to understand the results of the optimizer so I could know where to tweak as necessary.

Appreciate the patience while I attempt to harness the power!

No problem.  I don't know for sure why things behaved the way they did, but what I often find is that having constraints and objective functions that are very similar ("distance to body" and "periapsis altitude" for example), you may get funny behavior.  But as you suggested, yes, all this is really something you just learn over time.  Keep playing with MA (and give Launch Vehicle Designer a go - it's basically an advanced MA with a more powerful way to structure what your vehicle is doing).  You'll get it in no time!

[Arrowstar]

Right, here's KSPTOT v1.6.5 pre-release 6 that resolves the MA optimization crash issue I mentioned above.

[Drew Kerman]

Ok @Arrowstar I'm going to brain dump here cause I was hoping writing it all out would make something click and turn a light on inside my head. No such luck. Maybe it will come to me tomorrow after I step away for a while. If you want you can follow along with this excel analysis sheet I made of my recent mission earlier this week. It will open to the first chart and I'll work through them in order.

First tho, a quick description of the mission itself. The Ascension Mk1 is the same exact lift stage for the Ascension Mk2. Originally the Mk1 tried for orbit however the control surfaces on the fins did not have enough pitch authority for it turn over enough for an efficient orbital ascent given the fuel available. Now the lifter is going to use new guidance fins where the whole fin actuates, producing much more control authority. But we're still not sure it's good enough so the lifter is flying to test them without the orbital stage and SRBs and expensive orbital probe payload. Because the lifter isn't lifting as much, it can fly faster but this will increase airflow and give the fins more authority than when it's moving slower with the full Mk2 stack. So the mission is designed to throttle back the engine to maintain speed comparable to a Mk2 while following the same orbital ascent trajectory. If it fails, we don't lose the orbital stage & payload.

So the Mk2 ascent into orbit was modeled first in LVD, then the lifter-only ascent was designed to match it (what I posted earlier with the plots). Ok, let's move on to the charts:

Atm Pres - looks good, thanks again for the improvements!

Atm Density - there was some noticeable discrepancy even at the default plot zoom level shown here so I added VOID data for a third opinion. Seems to agree more with LVD so I'll chalk this up to the kOS code I'm using from someone else that I don't really understand is a bit rough

Atm Temp - at the same time tho there's a lot more disagreement about temperature, which could be why the density doesn't match up so well. Sometimes VOID agrees with kOS, sometimes with LVD and a bit less often with neither

Cd - I had to approximate the shape of the rocket's nose based on previous flight data. The nose for that rocket was more conical and the nose on this one was more ogive so this rocket ended up having less drag. I purposely didn't model too exact past 45km, which is MECO for the lifter when carrying the Mk2 stack

Dyn Pres over Time/Alt - the next two plots make sense given the Cd was larger than it should have been

Alt over Time - okay so first point where we see things didn't quite go as planned. The rocket (kOS data) starts to deviate at ~60s and reaches 45km MECO ~5s later than planned (LVD data) to match up with what the Mk2 would have done

Vel over Alt - again the plan (LVD) matches what the Mk2 would do but the rocket first goes too slow and then too fast. This is a bit confusing because the prev plot only deviates once - you can see it happen around the same time here too. But if the Mk2 was supposed to reach 45km sooner as per the previous plot, how did it get there first when the lifter (kOS data) ends up moving faster by then?

Vel over Time - This seems to clear up some confusion because we see here that although the lifter ends up moving faster by 45km, the Mk2 accelerates faster. This is a bit surprising though because the lighter lifter shouldn't have any trouble matching acceleration...

Pitch over Time - 60s deviation is visible here, and okay so the slower pitch-over would explain why the rocket isn't accelerating as fast as it should be

Pitch over Alt - this match up across all three data sets confirms though that the lifter is pitching over just as it is supposed to, at least relative to altitude

Pitch vs Calc - the ascent in LVD is based on this quadratic fit function, and the plot here shows the actual flight pitch compared to the direct values calculated by that function for the given altitude. So we can see the rocket is flying not just as designed in LVD but as programmed in the kOS flight code

Throttle - again we can see at 60s deviation begins as the rocket is pitching over slower and hitting specific altitudes later, the throttle adjustments tied to those altitudes are also happening later

I'm not understanding the effect velocity is having. Based on what I'm seeing in the Vel over Alt plot, why am I not also seeing the kOS data crossing back over the LVD/Mk2 data in the other plots? Take the Pitch over Time plot for example. Okay at 60s according to Vel/Alt the lifter is moving slower, so yes the pitch rate would also be slower since the pitch function is directly linked to altitude and a slower moving rocket will not climb as fast. But then at ~96s the Vel/Alt plot shows the lifter moving faster than the Mk2, but the pitch-over rate does not also increase in the Pitch/Time plot? I'm missing something...

Bonus round, I added a few more plots to see if I just wasn't seeing the right data

Fuel flow - matches well with throttle

Mass - seems like LVD is a teensy bit on the light side but no huge discrepancy here

Thrust/Time - matches well with throttle settings over time, but what is up with the thrust discrepancy?

Thrust/Alt - same discrepancy here but actually matches up with higher altitude. Too tired right now to understand correlation - although worth noting below 20km is where the Atm Density most visibly deviates in that previous plot

 

Edited January 24, 2020 by Drew Kerman

[Drew Kerman]

Separate post here to request a Reference Area output in the GA tool. Just an easy way to check to make sure all drag state changes are using the proper value throughout the course of the ascent and are changing at the proper event times (staging and whatnot)

[Arrowstar]

16 hours ago, Drew Kerman said:

Ok @Arrowstar I'm going to brain dump here cause I was hoping writing it all out would make something click and turn a light on inside my head. No such luck. Maybe it will come to me tomorrow after I step away for a while. If you want you can follow along with this excel analysis sheet I made of my recent mission earlier this week. It will open to the first chart and I'll work through them in order.

<snip>

 

I'll take a look this weekend!  Thanks for sharing.

In the mean time,  I do want to share a new feature that's going to be in the next KSPTOT release within Launch Vehicle Designer.  For some time now I've had the desire to be able to change variable values directly without either having to go through the optimizer or the specific UI window where that value is set.  Enter the new "adjust variables" feature, available from the Optimization menu:

This simple UI shows you all of the variables that are currently active in your script (NOT including any you've disabled in the event listbox), the current value, and the bounds.  You can then adjust the value directly or with the slider.  As you adjust, the plot and state windows in the main LVD UI will update so you can see what's happening.  Saving will keep the changes you've made and canceling will restore the values of all variables to their original state.  I hope this feature is useful to people as they use LVD!

Oh, there is another enhancement.  The variable bounds warning that you see below now shows the actual variables that are near bounds and not just the events that they're on.  Should be more intuitive to use this way.

Let me know if you have any questions!

Edited January 25, 2020 by Arrowstar

[Drew Kerman]

4 minutes ago, Arrowstar said:

I'll take a look this weekend! 

thanks, hope you can intuit something or massage that data to bring reason to my madness

4 minutes ago, Arrowstar said:

As you adjust, the plot and state windows in the main LVD UI will update so you can see what's happening

yea I can def see this being helpful in learning to understand how things work depending on the changes that you make, with an easy revert after you've fiddled around. Nice!!

Also what in the hell is happening in that ascent figure??

[Arrowstar]

7 minutes ago, Drew Kerman said:

Also what in the hell is happening in that ascent figure??

Red and blue is the main vehicle.  Green is the first stage disposal trajectory after it falls away.  Black dotted line is the orbit of the space station we're meeting up with.  This is all with the new Set Kinematic State action I added a few pre-releases ago.  Pretty neat, huh?

[Drew Kerman]

@Arrowstar if you have a chance to look at my analysis, there is also a factor that I forgot to mention - aerodynamic turbulence of some sort sometimes causes my rockets to experience what I dub "roll shake" to various extents. Not sure what actually triggers the PID to react like this - it does it while under guidance for both kOS and the built-in SAS but I like to think it's shock waves off the nose reaching the fins since the rocket is so short. Here is what it looks like:

This is notable because it starts to occur at 66 seconds after launch, which is also when you see the pitch rate over time decrease. Since all 4 control surfaces are used to adjust for roll that means the two being used for pitch are not as effective anymore, plus the fins are also creating excess drag in their motions. The shake lasts like this throughout the engine burn after it starts (on some past flights it's only occurred for part of the ascent)

I still don't get what's up with that Vel/Alt plot tho

Also wow, just doing some more analysis and LVD has the rocket reaching 45km and shutting down the engine at L+2m14.918s the actual flight shut down was logged at L+2m14.87s  so despite it not following the pitch-over rate over time as planned, the excess velocity over what was planned led it up to nearly the same point. or am I not interpreting this correctly? Regardless that's my best error margin to date!!

Edited January 25, 2020 by Drew Kerman

[Drew Kerman]

also is it possible to make LVD files from before PR3 still load but just be read-only and can't simulate changes or save? I'm not bothered by having to swap versions to reference older files but it would just be nice to not have to

[AVaughan]

@Drew Kerman That looks like the control surfaces over-reacting rather than aerodynamic turbulence.  Turning down control authority might help.  Personally I never use moving fins on rockets, and just use engine gimbal for pitch control, and if I need roll control on a single engine stage I add either rcs or vernier thrusters (or in stock use a reaction wheel).

[Drew Kerman]

57 minutes ago, AVaughan said:

That looks like the control surfaces over-reacting rather than aerodynamic turbulence

the turbulence was just a bit of head canon to use for my RP since I don't believe even FAR actually does that but the control authority idea is one worth checking into thx

Edited January 26, 2020 by Drew Kerman

[Briso]

Hi. My program doesn't start. More precisely, it starts, but the program window itself does not appear. There is no antivirus installed on my computer.

-----------------------------------------------------------------

End of alarm. After a while, the program started.

Edited January 26, 2020 by Briso

[Drew Kerman]

1 hour ago, Briso said:

End of alarm. After a while, the program started.

yea this is a thing. Sometimes it starts up faster than others but all in all longer than most people expect. Maybe a note added to the OP will help

[Briso]

Is there a guide for Multi-Flyby Maneuver Sequencer ?

[Drew Kerman]

22 hours ago, Briso said:

Is there a guide for Multi-Flyby Maneuver Sequencer ?

not specifically, but the Solar System Edge tutorial packaged with the main KSPTOT release in the OP makes use of it, which should give you an idea of how it works. If not, ask questions

[Briso]

35 minutes ago, Drew Kerman said:

not specifically, but the Solar System Edge tutorial packaged with the main KSPTOT release in the OP makes use of it, which should give you an idea of how it works. If not, ask questions

Thanks

[Drew Kerman]

@Arrowstar how about shape selection options for the ground stations in addition to color? I have ground stations capable of reaching LKO and others for deep space, would like to visually distinguish the diff with shapes with colors for a second layer of denoting ranges

[Drew Kerman]

sorry to stack things up but I'm going through the orbital plan of my mission and it seems the Comm Network Analysis tool does not take into account line of sight? Here are the relevant files. The network analysis results show that my first LOS will occur at 723s into the mission, however if I use the GA tool to plot line of sight to the Ockr station I get a dropout at 690s. if you plot distance, then I'm going out of comms range at 723s but by then I would have already lost signal due to horizon cutoff.

Also when you look at the map of my comm stations, why does the signal jump from Kongo->Arekibo->Kravass->KSC? That's zig-zagging. It should just be Kongo->Kravass->KSC (I realize this doesn't actually make any difference at the speed of light, and maybe that's the point - the relay code is expecting a much larger distance going from one probe in space to another not from ground station to ground station)

Finally, something funky with the X axis plotting for the Total Path Distance. Labeling is right but when I select the point over 5000 it's actually shown as 6200 in the data tip.

[Drew Kerman]

yup, me again.

Tried to enable orbital decay and get an error. Repro is just load a default MA file, coast to TA of 0 with 1 rev and check the orbital decay use box.

I was curious to see around how much decay I would be experiencing if it were modeled in the game. I'm still on the fence about messing with this. I really want decay but if there's no mod support for it, the extra workload of backporting the KSPTOT calculations manually into the game would eventually be too much as my number of orbital sats grows

Edited January 29, 2020 by Drew Kerman