Jump to content

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


Recommended Posts

17 hours ago, Arrowstar said:

I can take a look at the MAT file and SFS file if you'd like me to confirm.

so you're asking for the MAT file from the first image, where I loaded the orbit from the SFS right?

new bug: when plotting porkchops (mmmm... porkchops) that exceed the max Dv in the options the program asks to allow it to be increased. If you say yes it tells you the option has been updated but when I check afterwards it is still the same. When it asks you to modify the synodic period for better results and you say yes that one works

Link to comment
Share on other sites

10 hours ago, Drew Kerman said:

so you're asking for the MAT file from the first image, where I loaded the orbit from the SFS right?

Yes, and the associated SFS please.  Whatever I need to reproduce that funny circular orbit in Kerbin's SoI.  Though as I explained in my previous post, I believe the cause is the way the orbit is defined in the SFS file (relative to Sun but with a position vector that places the spacecraft within Kerbin's SoI).  I'll check though.

Quote

new bug: when plotting porkchops (mmmm... porkchops) that exceed the max Dv in the options the program asks to allow it to be increased. If you say yes it tells you the option has been updated but when I check afterwards it is still the same. When it asks you to modify the synodic period for better results and you say yes that one works

Good find, fixed for next build!

Link to comment
Share on other sites

2 hours ago, Arrowstar said:

Whatever I need to reproduce that funny circular orbit in Kerbin's SoI

I think you're misunderstanding the post? That "funny circular orbit" is the orbit of the asteroid already around Kerbin (see the game screenshot). This isn't an asteroid that just came from sun orbit but one that's already been in orbit for some time.

Edited by Drew Kerman
Link to comment
Share on other sites

You know what, let me just do some more testing over here. What I'm going to try next is I'm going to load the asteroid in flight and pull orbital data straight from the game. Doing this will also update the orbital elements in the save file:

SFS Before flight scene load

SMA = 15600879.928555444
ECC = 0.235650487308428
INC = 130.48647876651356
LPE = 97.572253966611527
LAN = 106.555831899488
MNA = 0.96636781499848312
EPH = 39824530.459937654
REF = 1

SFS After flight scene load

SMA = 15600879.801565172
ECC = 0.23565053784577689
INC = 130.48648159392644
LPE = 97.572273881161507
LAN = 106.55583039375381
MNA = 2.5231528960659149
EPH = 40287624.98670084
REF = 1

KSPTOTConnect import

SMA = 15600.8798015712
ECC = 0.235650537845278
INC = 130.486481593927
LPE = 97.57227388119
LAN = 106.555830393757
TA = 157.075802287994
EPH = 40287621.2467002
REF = N/A

So from here on out I won't load the asteroid into the flight scene again and the SFS will remain at the values listed above - until the next SOI transition. I will let that happen from the Tracking Station rather than the flight scene and compare the results. Then I'll revert and allow the SOI transition to happen within the game and compare the results.

Next SOI transit is Feb 20th according to this data so it will be a while but I will report back eventually. Arrowstar if you want to play ahead rather than wait you can just manually assign the SFS orbit data above to anything you throw up into orbit and see what happens

Link to comment
Share on other sites

10 hours ago, Drew Kerman said:

Next SOI transit is Feb 20th according to this data so it will be a while but I will report back eventually. Arrowstar if you want to play ahead rather than wait you can just manually assign the SFS orbit data above to anything you throw up into orbit and see what happens

I can do that.  Remind me again what I'm looking for?  I've gotten a bit lost with all the things we've looked at recently. :)

Link to comment
Share on other sites

53 minutes ago, Arrowstar said:

I can do that.  Remind me again what I'm looking for?  I've gotten a bit lost with all the things we've looked at recently. :)

the exercise here is how accurate I can keep the propagation from KSPTOT in relation to the game. So, for the first attempt I made at predicting where and when this asteroid was going to cross into Mun's SOI it was accurate to milliseconds on the first encounter then off by a few seconds on the second encounter then off by weeks for the third encounter. I've plotted out 3 future encounters with the data I referenced above and now I need to see if they all remain accurate or start falling out of sync. The first attempt I made was pulling orbital data from the SFS file. This new attempt just above is from pulling data straight from the game through KSPTOTConnect. At no point moving forward in both instances did I load the asteroid into the flight scene, so the only time the SFS data should be updated is when it crosses an SOI

Edited by Drew Kerman
Link to comment
Share on other sites

On 12/19/2017 at 7:28 PM, Drew Kerman said:

the exercise here is how accurate I can keep the propagation from KSPTOT in relation to the game. So, for the first attempt I made at predicting where and when this asteroid was going to cross into Mun's SOI it was accurate to milliseconds on the first encounter then off by a few seconds on the second encounter then off by weeks for the third encounter. I've plotted out 3 future encounters with the data I referenced above and now I need to see if they all remain accurate or start falling out of sync. The first attempt I made was pulling orbital data from the SFS file. This new attempt just above is from pulling data straight from the game through KSPTOTConnect. At no point moving forward in both instances did I load the asteroid into the flight scene, so the only time the SFS data should be updated is when it crosses an SOI

Okay got it thanks.  I have a theory: if it's truly SoI transitions that seem to cause the issue, than it might be down to the fact that I actually target about 2 km into the SoI on every transition to make sure that when the code searches for the next SoI transition, it doesn't detect that the spacecraft is already outside the SoI it's supposed to be in.  Not surprisingly that causes problems.  I could see how this could compound over time like you're seeing, especially if more than a few SoI transitions are involved.

As a test, take a look at this next KSPTOT prerelease.  It's identical to the other in every way except that where SoI transitions are computed, I have greatly increased the fidelity of the SoI search routine with the addition of another algorithm that should get the accuracy down to about 10 meters or so.  Warning, this will slow down the calculation time some, but it's worth a shot.  Can you try this prerelease  out and see if the issue is still the same or if it improves any?

Thanks!

Link to comment
Share on other sites

16 hours ago, Arrowstar said:

Okay got it thanks.  I have a theory: if it's truly SoI transitions that seem to cause the issue, than it might be down to the fact that I actually target about 2 km into the SoI on every transition to make sure that when the code searches for the next SoI transition, it doesn't detect that the spacecraft is already outside the SoI it's supposed to be in.  Not surprisingly that causes problems.  I could see how this could compound over time like you're seeing, especially if more than a few SoI transitions are involved.

Yea I've been beginning to suspect SOI transitions more and more myself lately.  I did some testing and was getting some pretty weird results so I just kept things basic and tried the very first encounter with both PR6 and PR7

SFS test file

PR7 import from active vessel and propagation to first SOI encounter, the UT time after the event is 17156837.0167387 (3/30 @ 13:47:17) - without leaving the game for the Tracking Station and warping ahead, the actual SOI entry time is 3/30 @ 13:47:11

PR6 import from active vessel and propagation to first SOI encounter, the UT time after the event is 17156837.0969646 (3/30 @ 13:47:17) - without leaving the game for the Tracking Station and warping ahead, the actual SOI entry time is 3/30 @ 13:47:11

what - that several seconds discrepancy is huge, and like I said the last time I did an asteroid study the first SOI intercept was accurate to within milliseconds.

If you have v1.3.1 see if you can reproduce. It may just be from me still being on v1.2.2

Link to comment
Share on other sites

  • 2 weeks later...

so, haven't had time yet to test out any propagation stuff but I did finally get around to writing up that post about my interplanetary travel preparations I promised @wile1411 back in October - it actually took until the end of Dec for me to wrap up all the calculations! You can check it out here on the KSA site.

Link to comment
Share on other sites

14 hours ago, Drew Kerman said:

so, haven't had time yet to test out any propagation stuff but I did finally get around to writing up that post about my interplanetary travel preparations I promised @wile1411 back in October - it actually took until the end of Dec for me to wrap up all the calculations! You can check it out here on the KSA site.

Wow, phenomenal job!  That's all quite impressive! 

Link to comment
Share on other sites

I'm having a problem with planning a gravitational maneuver for Kerbin-Eve-Moho flight. Using "Solar system edge" tutorial as a reference, I managed to create a somewhat realistic plan. The problems started when I realised that my craft would not be able to do ejection burn at once and tried to assemble a flight plan with split burns. While fist two stages of building flyby trajectory (finding Eve and fitting inclination, RAAN and argument of periapsis), constraint violation cannot be lowered down to zero when performing optimization against SMa and eccentricity. I tried changing objective function, but it doesn't really help: only "Minimize distance..." gives somewhat better results. Still, the resulting trajectory doesn't bring me in vicinity of Moho. What I also tried: changing time of 1st ejection burn, tinkering with objective functions, replacing SMa with radius of periapsis, building coast to next ejection burn via "coast to apoapsis"+"coast to periapsis", and via "coast to periapsis" with Revs prior to coast = 1.

 

I'm using stable version of  KSP TOT 1.5.8. MFMS summary: https://pastebin.com/y0E7jYtw, plan with a single ejection burn https://drive.google.com/file/d/1F_05C_G0AXd7A_SOG3xyZh2NknrRBT_X/view?usp=sharing, plan with 2 ejection burns
https://drive.google.com/file/d/1BalsGEEYSLUgIBmnk96tQQRE_3XOqw8g/view?usp=sharing

 

What advice can you give on planning multiple-burn ejection trajectories? What has gone wrong in this case?

Link to comment
Share on other sites

I've been getting this error over and over again recently, during optimisation in the Mission Architect:

Gsn9xps.png

Here's the .mat file that causes it:

https://drive.google.com/file/d/1_oncvYfTLmVHH77dgq2zPs-4m9Vak_Dl/view?usp=sharing

 

I keep tweaking the optimisation parameters, but it keeps coming up during optimisation. Sometimes 55 iterations, sometimes 28, sometimes something else. Seems to happen every time though at this point.

I'm using KSPTOT 1.5.8, on KSP 1.3.1

Edited by Snoman314
Link to comment
Share on other sites

On 1/15/2018 at 8:56 PM, Snoman314 said:

I've been getting this error over and over again recently, during optimisation in the Mission Architect:

Gsn9xps.png

Here's the .mat file that causes it:

https://drive.google.com/file/d/1_oncvYfTLmVHH77dgq2zPs-4m9Vak_Dl/view?usp=sharing

 

I keep tweaking the optimisation parameters, but it keeps coming up during optimisation. Sometimes 55 iterations, sometimes 28, sometimes something else. Seems to happen every time though at this point.

I'm using KSPTOT 1.5.8, on KSP 1.3.1

This is now happening constantly, and I'm reminded that it's why I stopped playing KSP when 1.1 came out. Please help! Even the simplest circularisation mission optimisation crashes. I can't go back to the coarse controls of the vanilla node planning!

It seems to happen around the time the optimiser goes way off track. For example when I'm trying to perfect an orbit around the Mun, and the optimiser kicks the endstate out to Kerbol orbit or something like that. This is even when I've got the central body ID condition set. Not always though. The only workaround I've found so far is to try again several in-game hours later, with a different set of starting conditions. Sometimes this is just an inconvenience, but sometimes it's not an option, as it would mean missing the only window for a maneuver.

Usually the optimiser has made good progress, and if only I could use the results from one or two iterations back, I'd be happy. Instead everything is lost, and I keep getting the error every time I re-run it.

Edited by Snoman314
Added more info about the bug.
Link to comment
Share on other sites

10 hours ago, Snoman314 said:

This is now happening constantly, and I'm reminded that it's why I stopped playing KSP when 1.1 came out. Please help! Even the simplest circularisation mission optimisation crashes. I can't go back to the coarse controls of the vanilla node planning!

It seems to happen around the time the optimiser goes way off track. For example when I'm trying to perfect an orbit around the Mun, and the optimiser kicks the endstate out to Kerbol orbit or something like that. This is even when I've got the central body ID condition set. Not always though. The only workaround I've found so far is to try again several in-game hours later, with a different set of starting conditions. Sometimes this is just an inconvenience, but sometimes it's not an option, as it would mean missing the only window for a maneuver.

Usually the optimiser has made good progress, and if only I could use the results from one or two iterations back, I'd be happy. Instead everything is lost, and I keep getting the error every time I re-run it.

Looking at it now, sorry for the wait.

EDIT: Okay, in the mean time, use Script -> Execution Settings -> Optimizer Algorithm -> SQP

That should help things along.  There's something funny going on with the interior point solver.  The issue you're seeing is because the optimizer algorithm itself is passing NaN as some control variables, which is very strange (and very wrong).  I'm not sure why, could be something in my code that's causing it, or could not be.  I'll need to investigate.  Thanks for the report!

Edited by Arrowstar
Link to comment
Share on other sites

4 hours ago, Arrowstar said:

EDIT: Okay, in the mean time, use Script -> Execution Settings -> Optimizer Algorithm -> SQP

I've been meaning to ask for a while what the differences are for the algorithms because I have no clue how the option should be used. Can they be broken up into general use cases?

Link to comment
Share on other sites

2 minutes ago, Drew Kerman said:

I've been meaning to ask for a while what the differences are for the algorithms because I have no clue how the option should be used. Can they be broken up into general use cases?

You can read more about the various algorithms here. (Scroll to the bottom to the "algirthms" section.)

As for use cases, not really.  They are all generalized optimizers, and by their numerical nature, some will work better than others in different problems, but it's very hard to predict what those will be.  Interior point is the MATLAB recommended algorithm, and SQP is very good too.  (I use a modified SQP solver at work for trajectory design.)    Active Set is an older technique but I included it for completeness.  It's worth a shot if everything else fails.

An update on the bug above: I couldn't trace the problem to anywhere in my code, so I have set up the wrapper around the optimizer to call it quits with an error message if the optimizer ever returns NaNs for control variable values.  The message will instruct the user to use a different optimizer algorithm.  That seems to be the best I can do at the moment.  I can't debug the MATLAB internals because they are all encrypted in the software.

Link to comment
Share on other sites

Thanks for taking a look! Support ticket to MATLAB perhaps? :):confused:

I'm not seeing that Optimiser Algorithm option. Perhaps I have an old version? 

sQ594dq.png

Or maybe I'm looking in the wrong place?

As for the version, I did download the pre-release you linked on 22 December, but it was asking me to install a new version of the Matlab runtime, or something. I'm using the version off the first post.

Link to comment
Share on other sites

Just now, Snoman314 said:

Thanks for taking a look! Support ticket to MATLAB perhaps? :):confused:

I'm not seeing that Optimiser Algorithm option. Perhaps I have an old version? 

sQ594dq.png

Or maybe I'm looking in the wrong place?

As for the version, I did download the pre-release you linked on 22 December, but it was asking me to install a new version of the Matlab runtime, or something. I'm using the version off the first post.

Yes, I updated to the new version of the MCR for this upcoming release (which the pre-releases are on).  Can you grab the new MCR?  Should be for MATLAB R2017b.  The Optimizer Algorithm options are in the new pre-release only.

Speaking of which, here is the latest KSPTOT pre-release (v1.5.9 pre-release 8), which includes:

  • The error message discussed above when the optimizer hits a NaN for a control variable.
  • Messages to Output when you change optimizer algorithm.

Please let me know if you have any questions!  @Snoman314, grab this pre-release after the new MCR, please.

Link to comment
Share on other sites

I'm downloading now. I'll report back once it's finished, and I've tried the new pre-release. Thanks for your work!

++

OK, I have the new version, and changing the optimising algorithm seems to be a viable workaround. So thanks for that.

It's interesting watching the different optimisers work, SQP seems to be far more 'conservative' than Interior Point. It makes much smaller changes, that are more incremental in nature, following the gradient towards the optimal solution it seems. Whereas Interior Point jumps all over the place, as if it's mapping out the solution space, and then comes back towards the optimal point later. Or maybe I've just been staring at optimisation runs for too long! It's been far too long since I studied computational modelling to know what I'm talking about!:D

Regardless, thanks again for the update. Love your work, as always!

Edited by Snoman314
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...