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

[Arrowstar]

2 hours ago, DaMaster_Architect said:

Here you go!

https://1drv.ms/u/s!Ah1BfpUrSEKtgqVngMbmCaicUz7oYg

 

I must also point out that there's no dV manoever while in Jools SoI. Still though, the orbit after the aerobrake is a capture orbit, so it seems that an aerocapture has been performed. Perhaps the logmessage is outdated?

I ran through the code and there's definitely no aerobraking happening.  (I watched the code skip that part directly.)  The error is functioning as it should, as well.  In the MAT file, the periapsis altitude was in fact above the atmosphere of Jool. 

Some thoughts:

1) You are optimizing with many constraints on at once.  Instead, activate constraints it in stages: first target Jool, then set your periapsis altitude, then target your Laythe intercept, etc.  After each stage, turn off variables you no longer need and then turn off the corresponding constraints.  The idea is to keep the number of active constraints in MA's optimizer to a minimum because the optimization algorithm does better that way.

2) It looks like your TLI_Burn is occuring shortly after Jool periapsis if I'm seeing this correctly.

3) Keep up the practice with KSPTOT and Mission Architect.  It's not easy software to use because spacecraft mission design is hard stuff.  Keep asking questions here, too.  You'll get it!

[DaMaster_Architect]

9 hours ago, Arrowstar said:

I ran through the code and there's definitely no aerobraking happening.  (I watched the code skip that part directly.)  The error is functioning as it should, as well.  In the MAT file, the periapsis altitude was in fact above the atmosphere of Jool. 

Some thoughts:

1) You are optimizing with many constraints on at once.  Instead, activate constraints it in stages: first target Jool, then set your periapsis altitude, then target your Laythe intercept, etc.  After each stage, turn off variables you no longer need and then turn off the corresponding constraints.  The idea is to keep the number of active constraints in MA's optimizer to a minimum because the optimization algorithm does better that way.

2) It looks like your TLI_Burn is occuring shortly after Jool periapsis if I'm seeing this correctly.

3) Keep up the practice with KSPTOT and Mission Architect.  It's not easy software to use because spacecraft mission design is hard stuff.  Keep asking questions here, too.  You'll get it!

Okay, thanks for the help! I will give it a try with a more step-based approach, as opposed to optimizing everything at once. I'll post here the results, once I have them.

It's true that there is a TLI burn shortly after the aerobraking manoever. This was my approach to doing a course correction, in order to achieve an intersection with Laythes' SoI. 

[Gilph]

Another shout out to @Arrowstar and this awesome tool.

I'm sending some hardware to Gratian (GPP), a mid level outer planet. When I calculate a departure burn estimate from a parking orbit of 0 inclination, it was about 2300 dv (1400 prograde, -1650 normal). The high normal part was that I needed a 27 degree inclination, LAN of 7, orbit to leave Gael. Based on all of the fine information posted with respect to launching directly into the optimal orbit, I used the Launch Analysis tool to launch into a 27 degree inclination orbit with a LAN of 7 (it works with GPP, just need to input the correct planet and Lat, Lon of wherever you are lifting off from). The total deltav changed from 2300 to 1650, almost all prograde. That's serious savings. Not only was that great, the optimizer gave me burn that put me dead on the spot I wanted at the target.

GPP has 7 or so different launch sites at various locations. I can now figure out which launch site will give be the best inclination directly for each mission.

Thanks again.

[Gilph]

OK, it's been too long since I asked a silly question. I'd like to ask about time.

If I have a vessel in a parking orbit, and I'd like to do a porkchop plot/compute departure burn, I would pick a departure time, and the compute departure burn window will pop up. Since my vessel is already in orbit, I import the orbital parameters from KSP and I select the "Use" box to use the epoch and mean anomaly. The crunching happens and we get the departure burn parameters that we will use to create our MA optimization.

I have been playing around with MA and noticed that times are not always synced to certain events the way I would have expected:

1. If I import my initial state in MA and set a coast to the Departure Burn Time, I'll look at the true anomaly value. it is usually very different than the burn true anomaly value. Shouldn't the burn true anomaly and the value of true anomaly at burn UT be the same?
2. I started using two coasts: one to sometime before burn time, and a second to go to true anomaly from there. This way, I know I'm in the correct orbit number. But, I need to use a combination of burn time after Pe and viewing true anomaly values to make sure everything lines up right.

Once everything is set up and I get a successful optimization, I looked at the "view state after event" data for all the steps. The burn true anomaly and dv maneuver values all seem to be very close to the original departure burn calculation, but the times can be very different from the original by thousands of seconds. I can understand this if I use dummy values when the departure burn was calculated. But when I asked something similar in the past, you mentioned I should import the actual orbit and click the Use box, but it doesn't seem to improve things very much.

Is there any other process I can follow to get better timestamps on these events, or am I doing the correct process?

Thanks

 

[Drew Kerman]

I just noticed that if I open the Selective SOI Search window and select a few bodies, then close the window with the OK button, when I re-open it immediately afterwards everything is selected again.

[Drew Kerman]

whoo finally got to use that feature of being able to generate flyby trajectories I requested months ago!

This is the result of taking a captured asteroid and just propagating from one Mun encounter to the next, 58 times until I found that it crashed into Mun. Normally I would have had to create 58 Other Spacecraft with each new orbit in order to make something like this but now it's just a click away! I mean, I still did eventually make 58 Other Spacecraft so I could control line color and type to better show various orbits and such, but at least initially it was simple to get done. Good stuff Arrowstar

Now, lets see how well it works out in the game. I won't be visiting the asteroid in flight so the numbers should all match up, but this is also over 3.3 years of game time so floating point errors could have an affect? Will report back over the coming months of this long-term study haha

Edited November 9, 2017 by Drew Kerman

[Drew Kerman]

Also a question: I'm rendering some GA plots over a time period of years (based on the data in the prev post) and I would have imagined that selecting Days for the Independent Variable Time Unit would mean I'd get results faster but it's still rendering 608,116 points regardless of whether I choose days, minutes or even years. This doesn't make sense to me

[Arrowstar]

 

On 11/6/2017 at 9:18 AM, Drew Kerman said:

I just noticed that if I open the Selective SOI Search window and select a few bodies, then close the window with the OK button, when I re-open it immediately afterwards everything is selected again.

I'll take a look! 

51 minutes ago, Drew Kerman said:

whoo finally got to use that feature of being able to generate flyby trajectories I requested months ago!

This is the result of taking a captured asteroid and just propagating from one Mun encounter to the next, 58 times until I found that it crashed into Mun. Normally I would have had to create 58 Other Spacecraft with each new orbit in order to make something like this but now it's just a click away! I mean, I still did eventually make 58 Other Spacecraft so I could control line color and type to better show various orbits and such, but at least initially it was simple to get done. Good stuff Arrowstar

Now, lets see how well it works out in the game. I won't be visiting the asteroid in flight so the numbers should all match up, but this is also over 3.3 years of game time so floating point errors could have an affect? Will report back over the coming months of this long-term study haha

What was this for again?  Which feature? 

3 minutes ago, Drew Kerman said:

Also a question: I'm rendering some GA plots over a time period of years (based on the data in the prev post) and I would have imagined that selecting Days for the Independent Variable Time Unit would mean I'd get results faster but it's still rendering 608,116 points regardless of whether I choose days, minutes or even years. This doesn't make sense to me

This is just the display unit. The math is still always done in seconds. 

[Drew Kerman]

10 minutes ago, Arrowstar said:

What was this for again?  Which feature? 

Remember when I asked for a way for MA to create the plots that were displayed by the MFMS? I didn't think of using it for something like this at the time, but it works well.

10 minutes ago, Arrowstar said:

This is just the display unit. The math is still always done in seconds. 

oooh for the graph display? Ok. *waits patiently*

Anyone have any tips for taking the second-by-second tabular generated output in excel and stripping it down so that all that remains is data from once every minute, hour, day or year? Like, I just want a table of data where every row is one minute later than the last, or one hour later than the last, etc

Edited November 9, 2017 by Drew Kerman

[Drew Kerman]

On 11/9/2017 at 3:34 PM, Drew Kerman said:

Now, lets see how well it works out in the game. I won't be visiting the asteroid in flight so the numbers should all match up, but this is also over 3.3 years of game time so floating point errors could have an affect? Will report back over the coming months of this long-term study haha

Hrmm, already off to a rough start. So I had the first encounter ingame and was going to put the new orbital data into the mission file but first I had to advance events up to the point of the new orbit. After I did this though I ended up with a completely different result several events later and I'm not sure why. Repro steps:

1. Open mission file
2. Right-click on event 4 and select "Advance Script Up To Selected Event"
3. Wait a minute or so for it to churn
4. MA now tells me it will no longer take 100+ revs to get another encounter several events later

I don't get what's happening here, as I did not even put in the new orbital data yet, I just advanced the script which should keep everything else the same right? I checked the Initial State orbit properties after the script advance against the orbit that should be applied to event 4 in the original mission file and they match up exactly. Soooo where's the deviation?

[Drew Kerman]

another thought on the MFMS - there's no visible constraint for how close you can fly by the sun when plotting these trajectories. Is there a built-in constraint? If the MFMS is just taking things as close as it needs to to nail down a trajectory I would like to propose a change to adding a constraint as I think changing that during mission planning so your spacecraft doesn't overheat would be a significant altercation of the original trajectory plan given the sun's influence, possibly enough to void all flybys plotted afterwards

Edited November 21, 2017 by Drew Kerman

[csatlos]

@Arrowstar, first I just wanted to thank you for a great tool and all the time you've put into it.

I think I've run into some kind of bug in v1.5.8 which is preventing operation of the TOTConnect in order to get real-time data from my local machine (same one that runs the game). I originally ran into the error on KSP v1.2.2 (with RSS and Realism Overhaul plus a bunch of other mods) but I've re-tested on KSP v.1.3.0 (with a few mods, but nothing huge).

I can open the MCC Real Time System UI and when I click on "Test Connect to Remote Host", I get an accurate list of vessel (which leads me to believe the plugin is correctly loaded); however, when i select a vessel and click, "Connect to Real Time System", I hear a windows error chime in the background and nothing connects.

A dive into the KSP.log shows some KSPTOT Connect errors such as, "". I've links the full logs from both v1.3.0 and v1.2.2 in case it helps. I went back to KSP TOT v1.5.7 and it seems to connect OK even using the KSP TOT Connect plugin from 1.5.8 (suggesting perhaps a change to the main program and not the plugin is causing the issue).

[Drew Kerman]

@csatlos reproduce the error and also post the ksptot.log file from the main install folder after you hear the chime

[csatlos]

22 hours ago, Drew Kerman said:

@csatlos reproduce the error and also post the ksptot.log file from the main install folder after you hear the chime

@Drew Kerman,

Thanks for looking into this. Here's the ksptot.log and I've also included another the KSP game log file from the same instance that was used to get the TOT error in case you want to look at both together.

[Drew Kerman]

3 hours ago, csatlos said:

Thanks for looking into this

Oh I'm not looking into it, I'm just helping to ensure arrowstar has all the info he needs to look into it when he is able to. He's around, just really busy currently

[Arrowstar]

On 11/13/2017 at 9:18 AM, Drew Kerman said:

Hrmm, already off to a rough start. So I had the first encounter ingame and was going to put the new orbital data into the mission file but first I had to advance events up to the point of the new orbit. After I did this though I ended up with a completely different result several events later and I'm not sure why. Repro steps:

1. Open mission file
2. Right-click on event 4 and select "Advance Script Up To Selected Event"
3. Wait a minute or so for it to churn
4. MA now tells me it will no longer take 100+ revs to get another encounter several events later

I don't get what's happening here, as I did not even put in the new orbital data yet, I just advanced the script which should keep everything else the same right? I checked the Initial State orbit properties after the script advance against the orbit that should be applied to event 4 in the original mission file and they match up exactly. Soooo where's the deviation?

So... I'm not exactly sure what's happening.  It doesn't make sense, as you said, because the way that function works just grabs the initial state from the event that you're advancing up to, deletes everything between the current initial state and the selected event, and rewrites the initial state event.  Any chance you can reproduce this on a file that has fewer events so that it's easier to run?

On 11/20/2017 at 9:52 PM, Drew Kerman said:

another thought on the MFMS - there's no visible constraint for how close you can fly by the sun when plotting these trajectories. Is there a built-in constraint? If the MFMS is just taking things as close as it needs to to nail down a trajectory I would like to propose a change to adding a constraint as I think changing that during mission planning so your spacecraft doesn't overheat would be a significant altercation of the original trajectory plan given the sun's influence, possibly enough to void all flybys plotted afterwards

I hadn't thought of this, good idea.  How close would you suggest the minimum should be?

On 11/21/2017 at 5:50 PM, csatlos said:

@Arrowstar, first I just wanted to thank you for a great tool and all the time you've put into it.

I think I've run into some kind of bug in v1.5.8 which is preventing operation of the TOTConnect in order to get real-time data from my local machine (same one that runs the game). I originally ran into the error on KSP v1.2.2 (with RSS and Realism Overhaul plus a bunch of other mods) but I've re-tested on KSP v.1.3.0 (with a few mods, but nothing huge).

I can open the MCC Real Time System UI and when I click on "Test Connect to Remote Host", I get an accurate list of vessel (which leads me to believe the plugin is correctly loaded); however, when i select a vessel and click, "Connect to Real Time System", I hear a windows error chime in the background and nothing connects.

A dive into the KSP.log shows some KSPTOT Connect errors such as, "". I've links the full logs from both v1.3.0 and v1.2.2 in case it helps. I went back to KSP TOT v1.5.7 and it seems to connect OK even using the KSP TOT Connect plugin from 1.5.8 (suggesting perhaps a change to the main program and not the plugin is causing the issue).

I can take a look.  Thanks for the report!

[Drew Kerman]

6 minutes ago, Arrowstar said:

Any chance you can reproduce this on a file that has fewer events so that it's easier to run?

Well, I can pare down what is there to see how low I can get the event list before the propagation works properly, but have you looked close at what may be happening for the coast event that is causing the problem? I'm doing 100 revs prior to the second search for an SOI hit - it's the only point in the mission plan where I have to search further than the max number of allowed revs to find the next encounter. If there's nothing suspicious there you can see, I will try deleting like 10 events at a time and re-running the script advance to see what happens

17 minutes ago, Arrowstar said:

How close would you suggest the minimum should be?

No idea. I'm not familiar with the thermal aspects of KSP at all yet. It could depend greatly too on the mods people are using. Are you aware of any reasonable safe altitude for our own sun? Might be a generic value that could be calculated for Kerbin's sun based off that. Ultimately it should probably be a user-setting, but with the suggested minimum already input. If you really need suggestions, I would try posting a question on reddit or here on the forums about it for people with more experience to chime in

[Arrowstar]

5 hours ago, Drew Kerman said:

Well, I can pare down what is there to see how low I can get the event list before the propagation works properly, but have you looked close at what may be happening for the coast event that is causing the problem? I'm doing 100 revs prior to the second search for an SOI hit - it's the only point in the mission plan where I have to search further than the max number of allowed revs to find the next encounter. If there's nothing suspicious there you can see, I will try deleting like 10 events at a time and re-running the script advance to see what happens

As far as I can tell, it's a solver tolerance issue.  There's a piece of numerical code that is responsible for figuring out if a trajectory crosses an SoI and the search routine for that code uses a tolerance value to figure out when to stop when determining when the SoI crossing occurs.  Because of that tolerance, things might execute slightly differently here and there depending on initial conditions, and I suspect that's what's the at the root of the problem.  If I can get a simpler case that demonstrates the issue, I can play around with this more.

Quote

No idea. I'm not familiar with the thermal aspects of KSP at all yet. It could depend greatly too on the mods people are using. Are you aware of any reasonable safe altitude for our own sun? Might be a generic value that could be calculated for Kerbin's sun based off that. Ultimately it should probably be a user-setting, but with the suggested minimum already input. If you really need suggestions, I would try posting a question on reddit or here on the forums about it for people with more experience to chime in

I've added a constraint in for next release.  Right now it's just MFMS central body radius + atmosphere height as the minimum periapsis of the transfer orbits.  I assume this will be fine for now as it will stop people from running into the central body.  If that's insufficient and there's enough demand, I can look into adding more flexibility to that number.

On 11/21/2017 at 5:50 PM, csatlos said:

@Arrowstar, first I just wanted to thank you for a great tool and all the time you've put into it.

I think I've run into some kind of bug in v1.5.8 which is preventing operation of the TOTConnect in order to get real-time data from my local machine (same one that runs the game). I originally ran into the error on KSP v1.2.2 (with RSS and Realism Overhaul plus a bunch of other mods) but I've re-tested on KSP v.1.3.0 (with a few mods, but nothing huge).

I can open the MCC Real Time System UI and when I click on "Test Connect to Remote Host", I get an accurate list of vessel (which leads me to believe the plugin is correctly loaded); however, when i select a vessel and click, "Connect to Real Time System", I hear a windows error chime in the background and nothing connects.

A dive into the KSP.log shows some KSPTOT Connect errors such as, "". I've links the full logs from both v1.3.0 and v1.2.2 in case it helps. I went back to KSP TOT v1.5.7 and it seems to connect OK even using the KSP TOT Connect plugin from 1.5.8 (suggesting perhaps a change to the main program and not the plugin is causing the issue).

Issue resolved for next release.

[Drew Kerman]

23 minutes ago, Arrowstar said:

If I can get a simpler case that demonstrates the issue, I can play around with this more.

would the same file but with just way less events do? Deleting them one by one takes a while so I could understand not wanting to deal with that tediousness, but I will do that if it will help. Otherwise I don't have anything else to work with at the moment

24 minutes ago, Arrowstar said:

I assume this will be fine for now as it will stop people from running into the central body

I wasn't really concerned about running into the sun I was more worried about the heat from the sun destroying things before you even got close to the atmosphere. I suppose I could Hyperedit a probe at various distances to see how common stock parts handle it...

[Arrowstar]

12 minutes ago, Drew Kerman said:

would the same file but with just way less events do? Deleting them one by one takes a while so I could understand not wanting to deal with that tediousness, but I will do that if it will help. Otherwise I don't have anything else to work with at the moment

If that's all it is, I can do it via MATLAB's internal variable editor.  No need for you to put the work in.  Just tell me which event to trim to.

Quote

I wasn't really concerned about running into the sun I was more worried about the heat from the sun destroying things before you even got close to the atmosphere. I suppose I could Hyperedit a probe at various distances to see how common stock parts handle it...

Got it!  So how would you like to see the constraint implemented then?  If it's fairly easy, I can put it together however you'd like.

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

In other news, I've begun migrating over to MATLAB R2017b.  I suspect v1.5.9 (or maybe I'll call it 1.6.0, haven't decided yet) will be running on this version of MATLAB.  Unfortunately, there appears to be an annoying issue with the way the SOI transitions are computed and I've noticed differences in the way the same mission plan is executed on the same code.  I suspect neither is technically wrong and it's just a matter of some tolerances somewhere, but it's something to track down.  Anyway, stay tuned!

[Drew Kerman]

4 hours ago, Arrowstar said:

Just tell me which event to trim to

It's event 19 that always comes up with the problem, as event 18 is where I'm coasting for 100 revs. So Try trimming to like event 20? Whatever you think is best

4 hours ago, Arrowstar said:

So how would you like to see the constraint implemented then?  If it's fairly easy, I can put it together however you'd like.

I envisioned just an additional text box. You could probably place it beside the Number of Runs box, shorten than caption to "# of Runs" and title the other text box "Min Sun Distance" with a [km] label next to it. This should probably be disabled if Sun isn't set as the central body, or it could just be ignored

[Arrowstar]

17 hours ago, Drew Kerman said:

It's event 19 that always comes up with the problem, as event 18 is where I'm coasting for 100 revs. So Try trimming to like event 20? Whatever you think is best

I'll take a look!

Quote

I envisioned just an additional text box. You could probably place it beside the Number of Runs box, shorten than caption to "# of Runs" and title the other text box "Min Sun Distance" with a [km] label next to it. This should probably be disabled if Sun isn't set as the central body, or it could just be ignored

Okay, I've put together a new pre-release build for what I'm calling v1.5.9.  Here it is.  It contains the bug fix for the KSPTOTConnect issue and the new constraint for MFMS.

Note that this was build on a new MCR version, MATLAB R2017b.  You'll need a new MCR download to run this.  Grab the Windows MCR download on the row labeled "R2017b (9.3)".

https://www.mathworks.com/products/compiler/matlab-runtime.html

[Drew Kerman]

nice, I have the latest runtime installed and the new build up and running no problems. Still have a little over 300 trajectory routes to plot over the next few weeks so plenty of stress testing ahead. Let you know if I come across any issues. Like the way the new constraint is implemented, nice work!

[Arrowstar]

26 minutes ago, Drew Kerman said:

nice, I have the latest runtime installed and the new build up and running no problems. Still have a little over 300 trajectory routes to plot over the next few weeks so plenty of stress testing ahead. Let you know if I come across any issues. Like the way the new constraint is implemented, nice work!

Thanks! You'll probably notice that there are slight differences in the way that MA propagates stuff in this build.  It has to do with the SoI transition code, I'm still pinning it down. 

[Drew Kerman]

1 hour ago, Arrowstar said:

Thanks! You'll probably notice that there are slight differences in the way that MA propagates stuff in this build.  It has to do with the SoI transition code, I'm still pinning it down. 

Not sure if this has anything to do with it but found this when propagating an asteroid from sun orbit to Kerbin SOI:

Very odd to see an asteroid enter, go to Ap then come crashing into Kerbin. It is supposed to crash into Kerbin the game shows this as well, but when I advanced to the asteroid entering Kerbin's SOI in the game it didn't show a trajectory like this. When I tried loading up 1.5.8 it loaded okay with the newer runtimes installed but when I went to do the same thing as in the screenshot it told me it couldn't even find an SOI to coast to. Here is the MAT file from 1.5.9 with the original asteroid orbit data. Note that this is with data imported from the save file. I found as I was working on this post that loading the orbit from the game produces the proper result. I've included the MAT file with the ingame orbit as well as the SFS file.