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

[Arrowstar]

On 9/3/2020 at 11:33 PM, Drew Kerman said:

• GA plots in LVD seem to now constrain the ability to move the data point cursor to within events only. It's a bit annoying to not be able to drag the data point cursor along the entire plot

This probably has to do with the fact that each event is now getting plotted as its own data series.   I think this ended up being necessary to support plotting each event with its own colors.  Sorry about the annoyance.

Quote

• Would you consider import/export of ground objects? Ground stations will be there every mission and ground bases too. Easier to import and delete what's not needed than to recreate every time

Yeah, I can look into this. 

Quote

• I did something in Ascension Mk2 #2 Ascent Optimized.mat that creates two problems I only notice after loading this file (neither happen with the default project loaded at LVD start):
  • Trying to add any additional objective function throws an error to the log
  • Going into the Celestial Body Catalog and clicking on Kerbin then selecting the atmosphere plot just locks up the whole program

• The first I suspect I've fixed previously because I can't reproduce on my end.  I'll keep looking into it though.
• The second is probably due to the atmospheric temperature caching I was doing.  I've disabled this for now in the code, it's turning out to be more hassle than its worth unfortunately.

Quote

• Arrow buttons are no longer disabled in the LVD figure view when I don't have any additional SOI or anything to jump to

Did they use to do this in the past?  I honestly don't remember lol.  Is there a bug associated with it or is it just weird?

Quote

• Is it possible for the figure view not to completely reset to the default view after a change is made to an event?

View -> Edit View Settings -> Uncheck "Update view axis limits"

Quote

• Been meaning to suggest for a while Camera Pan & Zoom be the default for the grabber and magnifying glass instead of Limits

There seems to be limited functionality for this under the hood because all camera actions ultimately seem to update an axes' limits.  That was just at a glance through the documentation though, I'll keep investigating.

Quote

• Could there be an addition to the Settings->Integration Settings for Global Output Step that would set the output step for all events? Not an override to individual settings, it would modify all the individual event settings

Done for next release.

Quote

• When setting a TWR throttle model it won't let me do so unless I set min/max optimizer values

Fixed for next release.

Quote

• I can set a coast to Apokee using any of these three methods, and the last one doesn't make sense (I got TA for Ap/Pe backwards from memory which is why I found a way to set to 0 initially):
  • TA termination 180 increasing/decreasing
  • TA termination 180 increasing
  • TA termination 0 decreasing

I'm working on this one but it's really obnoxious.  Having a true anomaly target of 0 deg does some weird things with the root finding built into the integration.  I'll keep poking at it.

EDIT: This one will not be solvable it looks like.  What's happening is that when you get 180 degrees away from 0.0, the true anomaly termination condition flips the sign of the value that gets passed to the integrator from positive (going away) to negative (going towards 0.0) and the integrator interprets this sign flip as a root and gets stuck at it.  There's no mathematical way around this that I can see.  If you need to go to zero, use a constraint and time as the termination condition.  This should work better.

(EDIT 2: There might be away for me to do this with flight path angle instead, but I'm not sure, so let's wait and see.)

Quote

Finally, there's an additional Ascension Mk2 #2 Orbit.mat file for MA which I used to create a circular orbit insertion burn. I then used the Maneuver Execution Assistant to tell me when to start the burn and its duration. I then attempted to recreate the burn in LVD (over time, not with a DV event) but did not get the same resulting orbit and am wondering what I did incorrectly

All MEA is doing is centering the burn delta-v over the arc of the burn.  I wouldn't expect it to match LVD, especially if the burn is longer.  MAE gives a better result than centering the burn in time, but it's still just estimating location based on a point  impulsive delta-v.  Use LVD for start times instead.

Edited September 5, 2020 by Arrowstar

[Fox62]

I'd like to request that the "Kerbin to Laythe" Mission Architect Tutorial be updated for the latest version of the Trajectory Optimization Tool - starting from the default configuration of the tool, the tutorial immediately deviates from what is seen by the person following the tutorial in that the porkchop plotter produces a different optimal transfer window and departure burn. This ultimately results in the person following the tutorial being unable to reach Jool, never mind getting as far as intercepting Laythe.

[Drew Kerman]

2 hours ago, Arrowstar said:

Sorry about the annoyance.

That makes sense tho, no big deal ultimately would rather have the color by event ability

2 hours ago, Arrowstar said:

Did they use to do this in the past?  I honestly don't remember lol.  Is there a bug associated with it or is it just weird?

One of the prereleases you had them disabled after I pointed out that they don't do anything under certain view conditions and I suggested they jump from event to event instead

2 hours ago, Arrowstar said:

There seems to be limited functionality for this under the hood because all camera actions ultimately seem to update an axes' limits.  That was just at a glance through the documentation though, I'll keep investigating.

Eh, just a very minor inconvenience to have to remember to switch the setting 99.9% of the time I need to zoom/pan. Would not bother looking further into it. It's basically an extension of my request to make the rotation tool selected by default

51 minutes ago, Fox62 said:

I'd like to request that the "Kerbin to Laythe" Mission Architect Tutorial be updated for the latest version of the Trajectory Optimization Tool - starting from the default configuration of the tool, the tutorial immediately deviates from what is seen by the person following the tutorial in that the porkchop plotter produces a different optimal transfer window and departure burn. This ultimately results in the person following the tutorial being unable to reach Jool, never mind getting as far as intercepting Laythe.

Let's do this instead - post a detailed report of your attempts to make it through the tutorial up to the point where you get stuck. Arrowstar can then guide you around the outdated material to get you started towards the next steps. You get stuck again, come back and do the same thing. Repeat until through the tutorial. Now you're served and Arrowstar has a clear idea of what needs to be revamped in the tutorial. In the meantime basic guidance is available here in the forum for anyone else looking to do the tutorial (*cough*me*cough*) before Arrowstar finds time to actually make the updates needed to the document

Edited September 5, 2020 by Drew Kerman

[Arrowstar]

On 9/3/2020 at 11:33 PM, Drew Kerman said:

hey @Arrowstar finally got to work on planning my upcoming second orbital mission (only 11 days away... no pressure...) and I have some bugs/feedback for you on the latest prerelease. Please download this package for the relevant files.

• GA plots in LVD seem to now constrain the ability to move the data point cursor to within events only. It's a bit annoying to not be able to drag the data point cursor along the entire plot
• Would you consider import/export of ground objects? Ground stations will be there every mission and ground bases too. Easier to import and delete what's not needed than to recreate every time
• I did something in Ascension Mk2 #2 Ascent Optimized.mat that creates two problems I only notice after loading this file (neither happen with the default project loaded at LVD start):
  • Trying to add any additional objective function throws an error to the log
  • Going into the Celestial Body Catalog and clicking on Kerbin then selecting the atmosphere plot just locks up the whole program
• Arrow buttons are no longer disabled in the LVD figure view when I don't have any additional SOI or anything to jump to
• Is it possible for the figure view not to completely reset to the default view after a change is made to an event?
• Been meaning to suggest for a while Camera Pan & Zoom be the default for the grabber and magnifying glass instead of Limits
• Could there be an addition to the Settings->Integration Settings for Global Output Step that would set the output step for all events? Not an override to individual settings, it would modify all the individual event settings
• When setting a TWR throttle model it won't let me do so unless I set min/max optimizer values
• I can set a coast to Apokee using any of these three methods, and the last one doesn't make sense (I got TA for Ap/Pe backwards from memory which is why I found a way to set to 0 initially):
  • TA termination 180 increasing/decreasing
  • TA termination 180 increasing
  • TA termination 0 decreasing
• Finally, there's an additional Ascension Mk2 #2 Orbit.mat file for MA which I used to create a circular orbit insertion burn. I then used the Maneuver Execution Assistant to tell me when to start the burn and its duration. I then attempted to recreate the burn in LVD (over time, not with a DV event) but did not get the same resulting orbit and am wondering what I did incorrectly

A few more updates on this:

• The bug with creating the additional objective function I believe is resolved now.
• The arrow buttons are only disabled in the View All mode.  I have left them active in the Group by SoI mode, even if there's only one SoI in the mission.  Would it make more sense to disable them in this case too?
• The true anomaly termination condition isn't going to be solvable, unfortunately.  It has to do with the way the integrator's event root finding works and the fact that true anomaly is a cyclical quantity that repeats (and jumps from 360 degrees to 0 degrees instantaneously, which root finding hates).  I would recommend only using true anomaly as a termination condition if you know that the target true anomaly is not on the other side of periapasis (if the target true anomaly is not near periapsis) or not on the other side of apoapsis (if the target true anomaly is near periapsis - this is your case here).
• I'm sorry, I completely misunderstood your last point and didn't see that you were doing it in Mission Architect initially.  I think my previous point still makes sense though: the differences between impulsive and finite duration maneuvers is going to result in differences in final orbit after the maneuver.  Since MAE doesn't propagate finite burns, it only estimates burn start based on centered delta-v, the fact that you got a different result is not unexpected.

I'll put out a pre-release today, hopefully, with some of the changes/fixes involved it in.

[Drew Kerman]

50 minutes ago, Arrowstar said:

Would it make more sense to disable them in this case too?

Eh, they don't seem to do any harm when I click on them - it's just that nothing happens so you may get questions about it

[Arrowstar]

Hi everyone,

Today I've compiled KSPTOT v1.6.7 pre-release 5.  Here's the change log:

• LVD: Added ability to set positive output step sizes for all active integrators on events.
• LVD: Boosted performance when looking for downward SoI transitions.
• LVD: Can now create event continuity constraints via a context menu accessed by right clicking on the sequential events listbox.
• LVD: Fixed a number of reported bugs (thanks, @Drew Kerman!)

Please let me know if you have any questions or I missed something.  Thanks!

(@Drew Kerman: I know I still need to look at importing/exporting ground objects.  This is more complicated than it appears, though, so bear with me for the time being.)

[Drew Kerman]

2 hours ago, Arrowstar said:

so bear with me for the time being

nice to have not need to have so take your time, thanks for the patch job!

[Drew Kerman]

also @Arrowstar I think I said this before but just as a reminder I want it to be clear that with regards to all the effort I'm making to improve the atmospheric model I of course do not expect it to ever be "perfect" where I can wind up with a rocket precisely positioned after ascent as planned. However I do want to work towards building up an understanding of just how accurate LVD can be so a proper error margin can be planned into missions

[Arrowstar]

2 hours ago, Drew Kerman said:

also @Arrowstar I think I said this before but just as a reminder I want it to be clear that with regards to all the effort I'm making to improve the atmospheric model I of course do not expect it to ever be "perfect" where I can wind up with a rocket precisely positioned after ascent as planned. However I do want to work towards building up an understanding of just how accurate LVD can be so a proper error margin can be planned into missions

It's all good!  I really want to get to the bottom of this, too. 

...so that's what I did tonight lol.  What I did was rewrite a portion of KSPTOTConnect to grab the vessel relative atmospheric pressure, temperature, and density, as KSP sees it, and write it to a CSV file.  I then plotted the calculations my code does for those quantities against the data KSP provided me.  Here's what I got.

KSPTOT is blue on top, KSP is red on top, and the difference is the bottom row.  The temperature is pretty off... but look at that.  KSP is using a linear interpolation model!  This whole time I figured they had some smooth curve through their data internally, but nope, they basically just draw straight lines.  Needless to say, I was shocked to see this.

Anyway, correcting for the difference in model type (switching mine to linear) yields:

This is obviously much better and the density differences are basically non-existent now.

I'll need to write some additional code to switch everyone over to the linear model for temperature and pressure curves, but all new KSPTOT sessions (for both MA and LVD) will have the linear model applied.

Btw, this also implies that the temperatures and pressures coming out of kOS are basically junk.  You might want to have a word with the developer if that is something you require to be accurate in the future.  It was pretty easy to grab from KSP itself, I just used the following:

            double atmoTemp = vessel.atmosphericTemperature;
            double atmoDensity = vessel.atmDensity;
            double atmoPress = vessel.staticPressurekPa;

Thoughts?

[Drew Kerman]

Minor complaint - I've noticed in the LVD case file I previously linked to that when I turn off auto script propagation (in this case to quickly go through and disable some optimizer values) the figure still updates. With all the view options I have set it takes about 10s to update between each toggle of the event's optimizer settings. Mainly that's because I have the ground objects visible. I disabled those and then it was only 3s between toggling.

Three related issues:

• Ctrl+F doesn't seem to do anything in regards to changing the toggled state of optimizer variables for an event. I tried the keys on both sides of my keyboard. Also tried Shift and Alt
• you can't completely unselect ground stations in the Edit View Setting. At least one must always be selected. Is this intended?
• if I pop out the view, after closing the figure any attempts to change the position of the timeline cursor generates a ton of error digs. Reloading the file makes it usable again tho

I got the LVD optimizer to give me a circular (or near enough for my purposes) orbit, so that worked well. I'm going to be interested in seeing during this mission how I use LVD and MA as the mission progresses

3 hours ago, Arrowstar said:

Thoughts?

no idea myself, but I can try to shed some light on this by paying a visit to the KSP mod dev discord server and seeing who shows up here to discuss this further.

Also I'm afraid I wasn't clear on what I was asking in regards to the new integrator step size setting. Well, I did say output but still should have added additional clarification to reduce the chance of confusion because I did think this could be misinterpreted. So what I'm really looking for is to globally modify the step size for the GA tool results. Unless I'm exporting data for analysis in excel I prefer to keep the output size at -1 so the GA plots faster

Edited September 8, 2020 by Drew Kerman

[taniwha]

Those differences look suspiciously like frame errors. KSP physics is/has been rife with them (things being out by one physics frame). ie, the vessel readings may be from where the vessel was in the previous frame.

[TranceaddicT]

7 minutes ago, taniwha said:

Those differences look suspiciously like frame errors. KSP physics is/has been rife with them (things being out by one physics frame). ie, the vessel readings may be from where the vessel was in the previous frame.

@Lisias just dealt with the frame error issue too regarding planes slide across the tarmac.  Ended up being this type of thing where friction values were getting lost and the resultant calcs were being done with less than accurate friction values. Then, depending on your rigs inherent bias, the plane slides left or right mostly.

[Drew Kerman]

33 minutes ago, Arrowstar said:

Thoughts?

Actually the data from my analysis packet showing the temp results from kOS under a stock game seems to show a pretty linear plot. I mean, yea it's a bit curvy but that's likely just the result of me only outputting values from kOS once per second instead of like once per 250ms to really get resolution on the pointy edges

[vitorboschi]

Hey @Arrowstar, got a new bug report.

I'm getting this error while the LVD script propagates:
 

Error using odezero (line 49)
odezero: an event disappeared (internal error)

Error in ode45 (line 353)


Error in ODE45Integrator/integrate (line 23)


Error in TwoBodyPropagator/propagate (line 35)


Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 171)


Error in LaunchVehicleEvent/executeEvent (line 162)


Error in LaunchVehicleScript/executeScript (line 293)


Error in ma_LvdMainGUI>propagateScript (line 173)


Error in ma_LvdMainGUI>runScriptMenu_Callback (line 1614)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('runScriptMenu_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

This is the .mat file. Just open and try run the script and you should get the error: https://www.dropbox.com/s/855rjnrkzt7vcmr/Main mission plan.mat?dl=0

[DBowman]

On 9/8/2020 at 2:30 AM, Arrowstar said:

 

• The true anomaly termination condition isn't going to be solvable, unfortunately.  It has to do with the way the integrator's event root finding works and the fact that true anomaly is a cyclical quantity that repeats (and jumps from 360 degrees to 0 degrees instantaneously, which root finding hates).  I would recommend only using true anomaly as a termination condition if you know that the target true anomaly is not on the other side of periapasis (if the target true anomaly is not near periapsis) or not on the other side of apoapsis (if the target true anomaly is near periapsis - this is your case here).
•  

Is it possible to loose the modulo on the true anomaly, so it goes 359, 360, 361? or translate the "seam" 180 degrees from the termination condition?

[taniwha]

0 to 360 should be reserved for when the solution is "near" the apoapsis. -180 to 180 should be used when the solution is "near" the periapsis. Note that the orbit class (in KSP) does all its true anomaly work in -pi to pi (ie, radians). Also, for orbital solvers, I recommend working in what I call "cs" space: the cos and sin of the true anomaly. This is nice because all of the desirable quantities (radius, position, velocity, acceleration, jerk/jolt (and more if you're so inclined)) can be computed directly from c (cos(ta) and s (sin(ta)), and, more importantly, the only singularities occur when the eccentricity is >= 1 (ie, the orbit is open (parabola or hyperbola)*). As a bonus, since you're already working with the cos and sin of the true anomaly, there's no need to compute them each iteration. Once the solution is found in "cs" space, the true anomaly can be found using atan2(s,c) (with conversion to degrees if so desired).

* The singularities occur at cos(ta) = -1/e (for a parabola, the apoapsis is at infinity, and for a hyperbola, it's negative meaning that the radius shoots out past infinity ("to infinity and beyond!") and becomes negative).

[Mare Ingenii]

@Arrowstar, I created an issue on your git repo as Issue 25.  I noticed a pretty large difference in LVD between PR4 and PR5  and am not able to get PR5 to close on the same solution that was found in PR4.  PR4 is on the left and PR5 is on the right.  This is an Eve gravity assist, then 2 orbits followed by a Kerbin assist out to Jool.

 

 

Edited September 11, 2020 by Mare Ingenii
incorrect URL for git repo issue

[Drew Kerman]

@Arrowstar potentially relevent discussion on kOS reddit:

 

[Borv413]

So, I downloaded the latest non-prereleaseed version last night. It broke almost immediately after i successfully did a Kerbin -> Duna Porkchop plot. I can not launch it again. Testing out if I can use the latest MATLAB compiler runtime and if it will fix it.

[Borv413]

ok, got that working(downloaded the prerelease version). now I'm trying to Create New Bodies File From KSP and that isn't working even when I'm in the flight scene. it is connecting according to the logs, but the executable side of it just says "No Data.

[Arrowstar]

2 hours ago, Borv413 said:

ok, got that working(downloaded the prerelease version). now I'm trying to Create New Bodies File From KSP and that isn't working even when I'm in the flight scene. it is connecting according to the logs, but the executable side of it just says "No Data.

Can I see your KSP log and your KSPTOT log files?

On 9/11/2020 at 10:12 AM, Mare Ingenii said:

@Arrowstar, I created an issue on your git repo as Issue 25.  I noticed a pretty large difference in LVD between PR4 and PR5  and am not able to get PR5 to close on the same solution that was found in PR4.  PR4 is on the left and PR5 is on the right.  This is an Eve gravity assist, then 2 orbits followed by a Kerbin assist out to Jool.

Can I see the MAT file that you're seeing this in?

[Borv413]

KSP log:https://drive.google.com/file/d/1fhTQiPspiaKRnyPCf2dSoenby9i1P5OG/view?usp=sharing

KSPTOT log:https://drive.google.com/file/d/1fPduAdbbdzcT6Owb5wQFldprWCj8DbpU/view?usp=sharing

Sorry if I'm not supposed to use google drive, this is the only way I sort of know.

[TranceaddicT]

55 minutes ago, Borv413 said:

Sorry if I'm not supposed to use google drive, this is the only way I sort of know.

As long as you're not shoving a log into a post or GitHub issue, any file sharing service is fine. 

[Arrowstar]

2 hours ago, Borv413 said:

KSP log:https://drive.google.com/file/d/1fhTQiPspiaKRnyPCf2dSoenby9i1P5OG/view?usp=sharing

KSPTOT log:https://drive.google.com/file/d/1fPduAdbbdzcT6Owb5wQFldprWCj8DbpU/view?usp=sharing

Sorry if I'm not supposed to use google drive, this is the only way I sort of know.

Have you tried creating the bodies file more than once?  KSPTOTConnect definitely packaged things up and sent the data.  This is pretty unusual.  I'm not sure what to say honestly.

[Borv413]

yes

could it be that since I am using a planet mod that re-parents Kerbin, it breaks it?