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

[Drew Kerman]

50 minutes ago, Arrowstar said:

Here you go.   I only fixed the interpolation for Kerbin but I figure that should get you off the ground (literally).

Yep, that's enough thanks!

Also my most recent flight this past week came up only 3km short target altitude on MECO, only 47km short on apokee and ~35km southwest of my target re-entry area. Could have been more on-target if I hadn't made too much of a conservative steering measure towards the end of the ascent:

I didn't want to overshoot the pitch hold at 45° so I had it lock to 45° at like 46.5° because I thought control authority would be lower that high but it snapped down to 45 really fast, dammit I also made the mistake of unlocking the steering after MECO while still in atmo which is why the actual pitch path fell off 45 at the end

My post-flight analysis will input these guidance errors into LVD and see if it shows similar results

Edited September 19, 2019 by Drew Kerman

[Arrowstar]

1 minute ago, Drew Kerman said:

Yep, that's enough thanks!

Also my most recent flight this past week came up only 3km short target altitude on MECO, only 47km short on apokee and ~35km southwest of my target re-entry area. Could have been more on-target if I hadn't made too much of a conservative steering measure towards the end of the ascent:

<snip>

I didn't want to overshoot the pitch hold at 45° so I had it lock to 45° at like 46.5° because I thought control authority would be lower that high but it snapped down to 45 really fast, dammit I also made the mistake of unlocking the steering after MECO while still in atmo which is why the actual pitch path fell off 45 at the end

Getting better...

Honestly, that looks great!  I'm really digging the fact that LVD can model these missions that well!  Thanks for sharing.

[Drew Kerman]

27 minutes ago, Arrowstar said:

I'm really digging the fact that LVD can model these missions that well! 

Yup, I will continue to work out "acceptable error margins" that anyone can apply to planning with LVD. If you have any suggestions on that which may not be obvious to this process, please share. I figure you guys also have to work this out for the software you use but I could be wrong or slightly misunderstood about it

[Arrowstar]

20 hours ago, Drew Kerman said:

Yup, I will continue to work out "acceptable error margins" that anyone can apply to planning with LVD. If you have any suggestions on that which may not be obvious to this process, please share. I figure you guys also have to work this out for the software you use but I could be wrong or slightly misunderstood about it

In real life our constraints are pretty tight.  We generally expect apogee and perigee altitudes to be within 1 km of their nominal values, and inclination and RAAN should be +/- 0.01 degree or so.  But real life also has lots of very smart people with decades of experience working on this stuff, so it's achievable.

Edited September 20, 2019 by Arrowstar

[Drew Kerman]

2 hours ago, Arrowstar said:

We generally expect apogee and perigee altitudes to be within 1 km of their nominal values, and inclination and RAAN should be +/- 0.01 degree or so.  But real life also has lots of very smart people with decades of experience working on this stuff, so it's achievable

CHALLENGE ACCEPTED

[AVaughan]

3 hours ago, Arrowstar said:

In real life our constraints are pretty tight.  We generally expect apogee and perigee altitudes to be within 1 km of their nominal values, and inclination and RAAN should be +/- 0.01 degree or so.

Mechjeb's PVG ascent guidance works pretty well for me most of the time. (RO/RP-1).  eg my last ascent target orbit: 150km x 900km @ 68 degrees.  Actual 150,000m x 900,004.9m @ 68.00003 degrees.  (It did kill the second stage a smidgeon early, and burnt a bit of rcs to raise apoapsis to 900km.  But another gametick from the second stage would have probably resulted in an even larger error in apoapsis, so that was probably as close to optimal as it could get given KSP's 20-50ms gametick).

[Arrowstar]

2 hours ago, AVaughan said:

Mechjeb's PVG ascent guidance works pretty well for me most of the time. (RO/RP-1).  eg my last ascent target orbit: 150km x 900km @ 68 degrees.  Actual 150,000m x 900,004.9m @ 68.00003 degrees.  (It did kill the second stage a smidgeon early, and burnt a bit of rcs to raise apoapsis to 900km.  But another gametick from the second stage would have probably resulted in an even larger error in apoapsis, so that was probably as close to optimal as it could get given KSP's 20-50ms gametick).

Sweet!  Now that is some good ascent guidance.

[Drew Kerman]

On 9/20/2019 at 11:05 PM, Arrowstar said:

Sweet!  Now that is some good ascent guidance.

I looked into it - it's based directly off a PEG paper by NASA - so it most certainly would work well... for Earth. I give LVD way more credit for being more generally applicable

On that note, I think we need to discuss other options for the linear atmospheric model used by LVD. That's where the biggest deviation is coming from, IMO. Take these two examples made with data from my latest launch (click to embiggen):

Now lets look at how well my rocket flew in comparison to what I programmed into LVD:

So my initial design (green) had some minor mistakes at the start with pitching over too fast and toward the end I didn't have enough pitch points to smooth out the curve. My actual ascent also made a noticeable error in dipping down into pitch lock too soon. I made some adjustments to my LVD ascent profile to match more closely to my actual flight data and there was some improvement (full plot with clicky):

Here the altitude in meters over orbital velocity shows that the adjust LVD profile sticks to the actual data a bit longer before diverging, which I would attribute to the adjustment made at the start of the ascent to not pitch over as fast. You can see improvement as well in the dynamic pressure being lower and closer to the actual values (Q over time):

Drag modeling was pretty on point as well IMO, seen here as Cd over time:

when you plot the Cd over altitude that blip in the beginning becomes negligible.

Thoughts?

[Drew Kerman]

On 8/28/2019 at 7:35 PM, Drew Kerman said:

@Arrowstar I have another SOI detection issue. Here is the MAT file. The game detected the SOI transition but MA did not. I did a distance check of the trajectory after loading it in from the game and sure enough (blue line is Mun's SOI boundary distance from the Celestial Body Catalog):

That's output with a default 1000 log entries per coast. It is a very brief encounter lasting 15 minutes. However despite my best attempts I could not get MA to find it. You'll see in the MAT file I have everything maxed out in the search attempt - Stricter SOI Search is enabled, SOI Search Tolerance is at 1.000000E-14 (02 doesn't work either on the other end - to be honest not sure which was the proper extreme value I should be using but 14 took longer to process so I'm guessing that's looking closest) and the Number of SOI Transition Search Attempts is at 100. Increasing the log events to 100,000 also didn't make a difference, nor did attempting to coast to TA over 2 revs (which was used to make the plot above) or using the Next SOI coast event. This could maybe be an issue with the duration of the encounter rather than the distance?

Found another miss in a trajectory a few encounters after this one. Is there perhaps any way to force the SOI encounter that I haven't thought of, or will this need to wait for a program fix?

[Drew Kerman]

23 hours ago, Drew Kerman said:

Found another miss in a trajectory a few encounters after this one. Is there perhaps any way to force the SOI encounter that I haven't thought of, or will this need to wait for a program fix?

durr, nevermind no fix needed anytime soon. I just remembered I've already advanced the game through several encounters and have the post-encounter orbit data. So I can just use that (shhhhhh! ) I don't have to actually propagate to that point from an earlier encounter like I was trying to do when I found the missed SOI

[Arrowstar]

@Drew Kerman: I checked and it does look like I have a linear interpolation on the atmospheric data, probably for performance reasons.  I can change it back to a smooth spline though for testing if that would help you.

Regarding the MA SoI transition miss, I will take a look this weekend or next week and see if I can't figure it out.  Thanks for bringing it to my attention.

[Drew Kerman]

27 minutes ago, Arrowstar said:

probably for performance reasons

This was my assumption. Please do change it to smooth and I will let you know if that is helpful enough to keep it despite any performance hit, or at least build in an option to switch to it for missions where accuracy is needed over faster design

To be clear I'd take the smooth atmosphere curve change over the MA SOI miss if you've only time to work on one at the moment

Edited September 27, 2019 by Drew Kerman

[Arrowstar]

On 8/28/2019 at 6:35 PM, Drew Kerman said:

@Arrowstar I have another SOI detection issue. Here is the MAT file. The game detected the SOI transition but MA did not. I did a distance check of the trajectory after loading it in from the game and sure enough (blue line is Mun's SOI boundary distance from the Celestial Body Catalog):

That's output with a default 1000 log entries per coast. It is a very brief encounter lasting 15 minutes. However despite my best attempts I could not get MA to find it. You'll see in the MAT file I have everything maxed out in the search attempt - Stricter SOI Search is enabled, SOI Search Tolerance is at 1.000000E-14 (02 doesn't work either on the other end - to be honest not sure which was the proper extreme value I should be using but 14 took longer to process so I'm guessing that's looking closest) and the Number of SOI Transition Search Attempts is at 100. Increasing the log events to 100,000 also didn't make a difference, nor did attempting to coast to TA over 2 revs (which was used to make the plot above) or using the Next SOI coast event. This could maybe be an issue with the duration of the encounter rather than the distance?

I had to add some additional code to jump into a different root-finding algorithm, but I think I've got this one figured out.  My bisection search code was throwing an NaN and not finding a solution that should have been obvious. 

Anyway, new build coming tonight with this and the smooth spline fit of the atmospheric data.  Keep in mind that you'll either need to create a new mission case or have me update your MAT file for you to use the new spline fit, because those splines are generated once when you start KSPTOT and used everywhere.

[Arrowstar]

Alright, here's the build of KSPTOT v1.6.4 pre-release 6.  The change log is short:

• Resolves an issue in Mission Architect's SoI transition search where the bisection search would return NaN while still returning a valid distance to target celestial body.
• All NEW MA and LVD cases will use spline interpolation for their atmospheric table interpolations.

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

[Drew Kerman]

nice, both fixes! Someone actually Ko-Fi'd me this weekend so I'll pass that on to you. I'll just remake the file just since I can't remember when it was originally made so want to make sure all the latest changes, not just the atmosphere, go into it. Thanks!

[Drew Kerman]

results! I was pretty disappointed at first when I rebuilt the LVD file and did not see a significant change in the end state of the rocket towards what actually happened. Still, a step in the right direction I think after plotting out the new data. Here is atmospheric density (click for full height plot):

Nicely matching the kOS and VOID data, which also applies to dynamic pressure (click to embiggen):

That's an awesome match! To clarify if needed - "LVD" is my original ascent design, "LVD Adjusted" is the original design modified to match the actual pitch closer and "LVD Smooth" is the adjusted profile with the smoother atmospheric model. But, and here is where the but comes in - the above plot is dynamic pressure over altitude. When you do it as dynamic pressure over time... (click to see LVD & LVD Adjusted plots)

We see that things aren't quite right and when we look at atmospheric density:

we find we have a lingering issue unfortunately. I've checked my bodies.ini file and the atmosphere data for Kerbin is not the same as the included .ini from stock data, so KSPTOT did pick up the changes made by the Better Atmospheres mod I mentioned I have installed. It may perhaps not be computing them properly or importing them properly? Can you add Atmospheric Temperature & Molar Mass to the GA tool? I have kOS logging these values now and I can compare them to the LVD output and see what variation exists there as well. Given how well the smoother pressure curve brought the dynamic pressure into line, I think if we can correct this we'll see a much closer on-target result. Here's the latest LVD file from which the "smooth" data was exported from if you need to look at it.

[Arrowstar]

8 hours ago, Drew Kerman said:

nice, both fixes! Someone actually Ko-Fi'd me this weekend so I'll pass that on to you. I'll just remake the file just since I can't remember when it was originally made so want to make sure all the latest changes, not just the atmosphere, go into it. Thanks!

Thanks for the tip!

58 minutes ago, Drew Kerman said:

results! I was pretty disappointed at first when I rebuilt the LVD file and did not see a significant change in the end state of the rocket towards what actually happened. Still, a step in the right direction I think after plotting out the new data. Here is atmospheric density (click for full height plot):

<snip>

Nicely matching the kOS and VOID data, which also applies to dynamic pressure (click to embiggen):

<snip>

That's an awesome match! To clarify if needed - "LVD" is my original ascent design, "LVD Adjusted" is the original design modified to match the actual pitch closer and "LVD Smooth" is the adjusted profile with the smoother atmospheric model. But, and here is where the but comes in - the above plot is dynamic pressure over altitude. When you do it as dynamic pressure over time... (click to see LVD & LVD Adjusted plots)

<snip>

We see that things aren't quite right and when we look at atmospheric density:

<snip>

we find we have a lingering issue unfortunately. I've checked my bodies.ini file and the atmosphere data for Kerbin is not the same as the included .ini from stock data, so KSPTOT did pick up the changes made by the Better Atmospheres mod I mentioned I have installed. It may perhaps not be computing them properly or importing them properly? Can you add Atmospheric Temperature & Molar Mass to the GA tool? I have kOS logging these values now and I can compare them to the LVD output and see what variation exists there as well. Given how well the smoother pressure curve brought the dynamic pressure into line, I think if we can correct this we'll see a much closer on-target result. Here's the latest LVD file from which the "smooth" data was exported from if you need to look at it.

Can I see a comparison plot of altitude vs time?  Because the quantities vs altitude plots look reasonable, I'm wondering if there's a non-trivial difference in your altitudes over time.

And yes, I can see about adding an atmospheric temperature plot.  Note that I did eliminate a small temperature adjustment factor in the interest of code performance, but given that atmospheric density looks spot on, I'm guessing that it doesn't have a huge impact.   I think the molar mass is fixed for each atmosphere, so that doesn't vary with time.

[Drew Kerman]

Yep, def non-trivial Same remains for the velocity/altitude plot I included in my last analysis post

Also there's no discernible difference in the LVD Adjusted plot

49 minutes ago, Arrowstar said:

given that atmospheric density looks spot on

wait what? I'm seeing significant deviation in the density plot. The atmospheric pressure is spot on

Also can the thrust profile chart vertical axis expand to accept numbers greater than 1? I'm using SRBs from a mod that has this thrust profile that ups the thrust to 1.1785

[Arrowstar]

29 minutes ago, Drew Kerman said:

Yep, def non-trivial Same remains for the velocity/altitude plot I included in my last analysis post

Also there's no discernible difference in the LVD Adjusted plot

wait what? I'm seeing significant deviation in the density plot. The atmospheric pressure is spot on

Also can the thrust profile chart vertical axis expand to accept numbers greater than 1? I'm using SRBs from a mod that has this thrust profile that ups the thrust to 1.1785

Okay, I see now, I was looking at your density plots from the last post, not the first one on this subject.  Sorry, reading these posts too fast.   Still, the density difference does seem small in comparison to the massive difference in altitudes that you're showing between what's being modeled and what's being flown in KSP.  Of course, that could be poor intuition on my part, too.  What would be interesting is to see what happens if you turn off the Kerbin atmosphere in KSP (is that possible in the debug menu?) and then turn off drag in LVD.  If your planned and flown trajectories are much closer then, then we'll know the difference is in atmosphere modeling.  Is that something you'd be able/willing to look into?

Regarding the chart: There's no discernible difference in the LVD adjusted plot between what and what?

I can look into changing the max allowable thrust profile scale factor, but it's not as straight forward as it sounds as there's something bounds checking code that depends on having a known, fixed maximum scale factor in there.  I guess I could always just set the max to be 2 or 10 or something like that...

[Drew Kerman]

43 minutes ago, Arrowstar said:

Is that something you'd be able/willing to look into?

I should be able to make a few tweaks to Kopernicus configs to shut down the atmosphere. I'll look into it

43 minutes ago, Arrowstar said:

There's no discernible difference in the LVD adjusted plot between what and what?

I didn't know if you wanted to also see the LVD Adjusted output but it drew right on top of the LVD Smooth, there was no visible difference

44 minutes ago, Arrowstar said:

I guess I could always just set the max to be 2 or 10 or something like that...

1.5 would be fine. if it's too much trouble, I can actually just edit the curve myself to max out at 1

[Drew Kerman]

2 hours ago, Drew Kerman said:

I should be able to make a few tweaks to Kopernicus configs to shut down the atmosphere. I'll look into it

yea so it's a simple true/false flag to switch off the atmosphere using Kopernicus but as I launched and saw the vaporous engine plume I realized disabling drag in LVD won't be enough since the atmosphere in LVD will still be there to affect the thrust of the engine - right?

[Arrowstar]

5 minutes ago, Drew Kerman said:

yea so it's a simple true/false flag to switch off the atmosphere using Kopernicus but as I launched and saw the vaporous engine plume I realized disabling drag in LVD won't be enough since the atmosphere in LVD will still be there to affect the thrust of the engine - right?

Well, you could just change your engine parameters to be vacuum levels regardless of atmosphere pressure.  That would be easier than changing the bodies.ini file and recreating the mission again I would assume.

[Drew Kerman]

1 hour ago, Arrowstar said:

Well, you could just change your engine parameters to be vacuum levels regardless of atmosphere pressure

Oh, right. Okay, I just have to get this stupid engine gimbal to work now. I can't use my fin control surfaces obviously right now the engine can't gimbal enough to pitch over downrange it seems. Rocket wants to fly the wrong way

Aha, it just so happens the engine I'm using had an error in its .cfg file for the engine gimbal thrust transform. Figures. Ok, let's see how this turns out...

Edited September 30, 2019 by Drew Kerman

[Drew Kerman]

Alright assuming I did this all right, here again is altitude over time with atmosphere:

And here it is without atmosphere:

I see an improvement, but there's still something off. Here is the LVD file so you can check that I set things up properly. I know in the game the atmosphere was definitely gone - the engine exhaust was fully expanded, all the FAR readouts were 0 and the engine was putting out max thrust for vacuum. The LVD file has all the drag update events removed, all the sequential events have only the Thrust force selected and the engine has its thrust and ISP the same for vacuum and sea level.

I'm burnt for the day, which means I'm not thinking of anything new to try or do or plot but if you have any ideas on what I should do I will hop on it.

[Arrowstar]

1 hour ago, Drew Kerman said:

Alright assuming I did this all right, here again is altitude over time with atmosphere:

And here it is without atmosphere:

I see an improvement, but there's still something off. Here is the LVD file so you can check that I set things up properly. I know in the game the atmosphere was definitely gone - the engine exhaust was fully expanded, all the FAR readouts were 0 and the engine was putting out max thrust for vacuum. The LVD file has all the drag update events removed, all the sequential events have only the Thrust force selected and the engine has its thrust and ISP the same for vacuum and sea level.

I'm burnt for the day, which means I'm not thinking of anything new to try or do or plot but if you have any ideas on what I should do I will hop on it.

Okay, thanks for looking into this!  Definitely a good effort.  The only two forces that should be acting on the vehicle at this point are gravity and thrust.  I would first check that the gravitational parameter of Kerbin is the same in LVD and KSP.  Next thing I would look at is making sure that the pitch profile is being executed as closely as possible to what's in LVD.  If that doesn't match, then the thrust vector will be wrong and you'll see differences.