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

[Drew Kerman]

Also, would like to mention that every now and then the game generates a near-Kerbin object that is supposed to be on a course through Kerbin's SOI but doesn't show an intercept in the game. If I load the orbit into MA and ask it to coast for the next SOI encounter it will find one. So it's like the reverse of the above issue because the game does eventually show the encounter when it gets closer. Not sure if there's a connection there or not

Edited April 11, 2018 by Drew Kerman

[Gilph]

Hi, found an issue with prerelease5 and MA. Here are the steps.

1. Open MA and put in normal steps to optimize a transfer burn
2. Run simple optimization
3. Optimizer finds a good solution and Final Spacecraft State in optimizer window shows a SOI result for your target
4. Select the result from the optimizer
5. The optimizer window closes, saying that it changed the DV_maneuver, but it looks like it does not. The original DV values are still there and the Final Spacecraft State in MA does not show the SOI change. It looks like nothing was updated after optimization.
6. Save the mission
7. Load the same mission
8. Now, you will see the results of the optimization.  DV numbers are changed, Final Spacecraft State shows the optimized result, and upload maneuver has the right values.

It looks like something is interfering with refreshing the windows after optimization.

Logs and mission are here  and show a bunch of weird errors

Thanks

 

[salajander]

17 minutes ago, Gilph said:

It looks like something is interfering with refreshing the windows after optimization.

Ah, good, someone else reproduced that - I thought I was seeing this with pr5, but I haven't had time to go back and repro.

[Drew Kerman]

good news is that the minor-step technique used to find the next actual Mun SOI intercept that I posted about earlier came within 10 seconds of being correct. Not sure if that's a reasonable margin of error but good enough for me

[Spacewall]

Greetings Kerbonauts,

I just installed KSPTOT and MecJeb and operating a new mission in Sandbox. When I warp on the launchpad the clock flips to the next day at the 6 minute.  Not 60 minutes - 6 minutes.  Any ideas? I have KSP 2089  Latest version: 2110

Thanks!!

Charles

[Gilph]

7 hours ago, Spacewall said:

Greetings Kerbonauts,

I just installed KSPTOT and MecJeb and operating a new mission in Sandbox. When I warp on the launchpad the clock flips to the next day at the 6 minute.  Not 60 minutes - 6 minutes.  Any ideas? I have KSP 2089  Latest version: 2110

Thanks!!

Charles

KSPTOT is a utility used outside of KSP, so it should not have affected anything. It has a KSPTOT Connect dll to allow for reading data from KSP which should not cause the issue you described.

[Drew Kerman]

UX request. Not a high priority but something that would be nice - the ability to constrain the start/end time of the graphical analysis tool using mission events. So instead of (or in addition to) the raw UT input boxes there would be a drop-down list of available events to choose from

[Drew Kerman]

On 5/3/2018 at 8:17 PM, Drew Kerman said:

good news is that the minor-step technique used to find the next actual Mun SOI intercept that I posted about earlier came within 10 seconds of being correct. Not sure if that's a reasonable margin of error but good enough for me 

just keeping notes here. following intercept was 7 seconds sooner than predicted by KSPTOT

[Zuppermati]

Quick question: why when I set the argument of periapsis in the initial state and I close, when I reopen it the value returns 0 and the true anomaly gets set to the value I set for the argument of pe?

Edited May 18, 2018 by Zuppermati

[Drew Kerman]

On 5/18/2018 at 12:56 PM, Drew Kerman said:

just keeping notes here. following intercept was 7 seconds sooner than predicted by KSPTOT

next one was only 4 seconds sooner than predicted. will continue to see how the accuracy changes over time, unless @Arrowstar comes back and tells me this is all irrelevant because there's a known error margin

Edited May 25, 2018 by Drew Kerman

[LGrim]

Hi, I got this tool a few days ago and started playing around with it. I managed to get a Kerbin-Eve-Jool-Eeloo encounter using the MMFS, so I started using Mission Architect to plan out the mission. I followed the tutorial in the Solar System Edge pdf exactly (apart from replacing the values for that mission with mine) and got up to optimising the Eve encounter. For some reason, it just isn't able to satisfy all the constraints. I've run the optimiser multiple times, but it still doesn't work. The pdf says to change the objective function back to Minimising Distance to Body if it can't satisfy all the constraints, but I've tried that and it doesn't work. I've triple checked all the values for the departure and arrival and everything. How would I go about fixing this? I can provide screenshots of things if you need them. Sorry if I've missed something obvious.

[Drew Kerman]

1 hour ago, LGrim said:

I managed to get a Kerbin-Eve-Jool-Eeloo encounter using the MMFS, so I started using Mission Architect to plan out the mission

You're a step ahead of me. I have a similar route picked out (except I use OPM so I'm going to Plock instead of Eeloo after Jool) but haven't got to mission planning yet. Hopefully arrowstar returns soon to assist

[Drew Kerman]

You can close the MFMS while it is running calculations Hopefully a warning dialog can be added at some point

[Drew Kerman]

On 5/18/2018 at 2:04 PM, Zuppermati said:

Quick question: why when I set the argument of periapsis in the initial state and I close, when I reopen it the value returns 0 and the true anomaly gets set to the value I set for the argument of pe?

ok I finally had this happen to me and definitely remember now asking the mod author about it. It's nothing to worry about, it's the same orbit and it happens when dealing with eccentric orbits of near 0. If you look back, I know there is a response from arrowstar explaining it but I couldn't find it after a few pages so it must have been a while ago

[Arrowstar]

On 4/10/2018 at 2:02 PM, Drew Kerman said:

Ok I did some more research into the issue and I have found that the Coast to Next SOI event is unable to find the encounter if it searches from further away than 4 days, 11 hours 27 minutes and 11 seconds. Repro:

1. Load MAT file
2. Add coast event to UT of 50833444
3. Add coast event to Next SOI (default # of search revs is enough)
4. Note no SOI encounter found
5. Edit UT coast and change to 50833445
6. Note SOI encounter is now found

Hi all,

Sorry for disappearing for a few months.  Life got a bit crazy, particularly at work.  Things still aren't fully back to normal but I'll do my best to keep up.  I do read all the notifications I get from the website about posts in this thread, I just don't always have the time (or energy!) to respond.

Anyway, @Drew Kerman, what you're seeing here is undoubtedly an issue with the technique used to find SoI transitions.  What's going on is that some code compares the position of a spacecraft along a trajectory with the SoI of a target body.  The function it searches on is ultimately the distance between the spacecraft and the body's SoI. It returns the time that such an SoI crossing occurs.  When you change the coast times like you did here, ultimately you're changing the numerical landscape of the problem in the key way.  I know it's frustrating (trust me, I deal with it at work daily! :)), but it's hard to fully eliminate this stuff without slowing down the SoI search code tremendously.  If it would be useful to you, I can investigate ways to make SoI search more robust at the expense of CPU time, but no promises of course.  To date, I've mostly concentrated on making it run fast and be reasonably accurate.

In addition, no root finder or optimizer is perfect and there is always going to be "slop" in the solution returned.  This is because it would essentially take infinite time, using numerical techniques, to find a solution to infinite precision.  Therefore, we assign a scaled tolerance to the problem, and when the solution is found to within that tolerance, we terminate the search.  This would explain your being 5-10 seconds off in a few later posts here and there.  Unless it's critical, I wouldn't worry about it too much.  It's finding the same solution as KSP, but just not matching it perfectly.  This is to be expected because I don't know how KSP is doing its SoI searches either...

On 4/11/2018 at 11:49 AM, Drew Kerman said:

Also, would like to mention that every now and then the game generates a near-Kerbin object that is supposed to be on a course through Kerbin's SOI but doesn't show an intercept in the game. If I load the orbit into MA and ask it to coast for the next SOI encounter it will find one. So it's like the reverse of the above issue because the game does eventually show the encounter when it gets closer. Not sure if there's a connection there or not

Does an SoI encounter actually exist in the game at any point?  I know KSP has trouble with SoI encounters on occasion, too.  If not, it would be super helpful to get an example MAT file and KSP save file that demonstrates this that I could compare.

On 4/25/2018 at 9:36 AM, Gilph said:

Hi, found an issue with prerelease5 and MA. Here are the steps.

1. Open MA and put in normal steps to optimize a transfer burn
2. Run simple optimization
3. Optimizer finds a good solution and Final Spacecraft State in optimizer window shows a SOI result for your target
4. Select the result from the optimizer
5. The optimizer window closes, saying that it changed the DV_maneuver, but it looks like it does not. The original DV values are still there and the Final Spacecraft State in MA does not show the SOI change. It looks like nothing was updated after optimization.
6. Save the mission
7. Load the same mission
8. Now, you will see the results of the optimization.  DV numbers are changed, Final Spacecraft State shows the optimized result, and upload maneuver has the right values.

It looks like something is interfering with refreshing the windows after optimization.

Logs and mission are here  and show a bunch of weird errors

Thanks

I'll take a look, thanks!

On 5/13/2018 at 3:56 AM, Drew Kerman said:

UX request. Not a high priority but something that would be nice - the ability to constrain the start/end time of the graphical analysis tool using mission events. So instead of (or in addition to) the raw UT input boxes there would be a drop-down list of available events to choose from

You can sort of do this now: right click the events in the mission sequence, and then copy their start or end UT times to the clipboard to paste in.  To me it always seemed like a fairly easy thing to do, but I'm open to feedback on what is a hassle and what is easy!

On 6/1/2018 at 1:24 PM, Drew Kerman said:

You're a step ahead of me. I have a similar route picked out (except I use OPM so I'm going to Plock instead of Eeloo after Jool) but haven't got to mission planning yet. Hopefully arrowstar returns soon to assist

Let me know how I can help.

On 6/10/2018 at 6:28 AM, Drew Kerman said:

You can close the MFMS while it is running calculations Hopefully a warning dialog can be added at some point

I'll take a look at this too!  That's not good.

4 hours ago, Drew Kerman said:

ok I finally had this happen to me and definitely remember now asking the mod author about it. It's nothing to worry about, it's the same orbit and it happens when dealing with eccentric orbits of near 0. If you look back, I know there is a response from arrowstar explaining it but I couldn't find it after a few pages so it must have been a while ago

This is it exactly.  Thanks for remembering and posting for me!

[Arrowstar]

On 6/1/2018 at 11:52 AM, LGrim said:

Hi, I got this tool a few days ago and started playing around with it. I managed to get a Kerbin-Eve-Jool-Eeloo encounter using the MMFS, so I started using Mission Architect to plan out the mission. I followed the tutorial in the Solar System Edge pdf exactly (apart from replacing the values for that mission with mine) and got up to optimising the Eve encounter. For some reason, it just isn't able to satisfy all the constraints. I've run the optimiser multiple times, but it still doesn't work. The pdf says to change the objective function back to Minimising Distance to Body if it can't satisfy all the constraints, but I've tried that and it doesn't work. I've triple checked all the values for the departure and arrival and everything. How would I go about fixing this? I can provide screenshots of things if you need them. Sorry if I've missed something obvious.

Hey there! Sorry for the delay in getting back to you.  Are you still having problems?  If so, please post your MAT file somewhere I can take a look at and I'll see what I can do for you.  Thanks!

[Arrowstar]

I took a look at the bugs reported earlier and managed to fix all of the UI-related ones.  I've compiled them into a new pre-release build: KSPTOT v1.5.10 pre-release 6.

Change log:

1. Resolved issue with the MA Delta-V dialog box not updating until another event is processed.
2. Resolved an issue with the main MA UI not refreshing after optimization.
3. Added a warning to MA if the user tries to close the application while the software is processing data (either because the UI is running the mission script or the orbit display is updating).

On 4/10/2018 at 2:02 PM, Drew Kerman said:

Ok I did some more research into the issue and I have found that the Coast to Next SOI event is unable to find the encounter if it searches from further away than 4 days, 11 hours 27 minutes and 11 seconds. Repro:

1. Load MAT file
2. Add coast event to UT of 50833444
3. Add coast event to Next SOI (default # of search revs is enough)
4. Note no SOI encounter found
5. Edit UT coast and change to 50833445
6. Note SOI encounter is now found

On second thought, could I get the MAT file you're seeing this in?  I want to understand it better now that I have a chance.  Thanks!

[Arrowstar]

On 4/10/2018 at 2:02 PM, Drew Kerman said:

Ok I did some more research into the issue and I have found that the Coast to Next SOI event is unable to find the encounter if it searches from further away than 4 days, 11 hours 27 minutes and 11 seconds. Repro:

1. Load MAT file
2. Add coast event to UT of 50833444
3. Add coast event to Next SOI (default # of search revs is enough)
4. Note no SOI encounter found
5. Edit UT coast and change to 50833445
6. Note SOI encounter is now found

On third thought @Drew Kerman, nevermind lol.  Completely ignore what I said before about all this.  I think you may have actually found a bug in my SoI transition detection code.  I think I fixed it... all of my test cases work properly anyways.  It's in the following new pre-release:

KSPTOT v1.5.10 pre-release 7

Can you take a look and see if this improves anything?  Thanks!

[Arrowstar]

On 4/8/2018 at 11:49 AM, salajander said:

Another feature request:

It would be grand if the Rendezvous Maneuver Sequencer and the Optimal Two Burn Orbit Change tools automatically changed the central body ("Orbiting About") when pulling in the orbit from the KSP TOT plugin. I can't tell you how many times I've forgotten to change it and had ... interesting ... results.

Also, the Orbit Change tool doesn't do anything when you right-click in the Final Orbit section and choose "Get Orbit from KSP".

Both of these bugs are now fixed in KSPTOT v1.5.10 pre-release 8.

Sorry for the pre-release spam tonight, I've just been going through and getting features in, compiled, and uploaded as I go through posts and see them.

[Drew Kerman]

@Arrowstar auuugh I just left for the week to do a fireworks show!!  hahhaa figures. Also, when I heard about the Northrop Grumman merger going through I figured that was probably a good portion of reason for your absence.

anyways, I will look at all the new stuff as soon as I am home this weekend and try to dig up those mission file examples 

also the change notes said you made a notice for MA but it was actually the MFMS that was running flyby routes at the time I closed the window accidentally

also also, pasting the UT times for events makes sense - the thing is I keep forgetting that window isn't modal haha

[Arrowstar]

9 hours ago, Drew Kerman said:

@Arrowstar anyways, I will look at all the new stuff as soon as I am home this weekend and try to dig up those mission file examples 

Thanks!  That will be fine.  No need to send anything if my bug fix solves all your problems... unlikely, I suppose, but one can dream.

Quote

also the change notes said you made a notice for MA but it was actually the MFMS that was running flyby routes at the time I closed the window accidentally

Right!  This is what happens when you read too quickly.  Thanks for the heads up.

Quote

also also, pasting the UT times for events makes sense - the thing is I keep forgetting that window isn't modal haha

Glad that will work.

[Arrowstar]

On 3/30/2018 at 2:27 PM, salajander said:

Hiya @Arrowstar - still loving this amazing tool.

I'm having some issues trying to use finite maneuver. This is the first time I've given it a shot, so perhaps I've done something wrong? I had an impulsive Duna transfer maneuver set up, then converted it to finite and re-optimized. I then uploaded it to KSP, but the burn didn't end up with an encounter, much less anywhere near my target. A course-correction burn was requiring ~200 m/s delta-v. If I just used the original impulsive maneuver instead, I ended up with an encounter and only need a few m/s of correction.

.mat files for finite and impulsive as well as a save file available here. I just now realized the save isn't from a vanilla install - the actual vessel in question (Duna Flyby Block 2) doesn't use any non-vanilla parts, though.

I took a brief look tonight and your trajectory seems sound. The kerbin to duna leg is pretty accurate. I haven't looked at the burn much though, I'll take a look tomorrow or Thursday. 

Have you had any luck?

[Arrowstar]

On 3/30/2018 at 2:27 PM, salajander said:

I'm having some issues trying to use finite maneuver. This is the first time I've given it a shot, so perhaps I've done something wrong? I had an impulsive Duna transfer maneuver set up, then converted it to finite and re-optimized. I then uploaded it to KSP, but the burn didn't end up with an encounter, much less anywhere near my target. A course-correction burn was requiring ~200 m/s delta-v. If I just used the original impulsive maneuver instead, I ended up with an encounter and only need a few m/s of correction.

Just an update: if this is the case, the only thing I can think of is that either the mass of the spacecraft is wrong some how, or the thrust of the engine used for the finite burn is wrong.  Check both of these.  If the impulsive maneuver is getting you there almost exactly, then these are the only two things that could be throwing you off.

[Arrowstar]

I've compiled a new pre-release that addresses the following issues: KSPTOT v1.5.10 pre-release 9

• Added SoI search tolerance menu option to Mission Architect;
• Added ability to perturb Mission Architect optimization variables by a percentage amount via menu;
• Fixed bug with Mission Architect optimization constraint analysis warning text; and
• Added warning dialog to MFMS is the user attempts to close the UI while MFMS is running.

Please let me know if you have any questions.  Thanks!

Edited June 14, 2018 by Arrowstar

[LGrim]

On 6/12/2018 at 12:51 AM, Arrowstar said:

Hey there! Sorry for the delay in getting back to you.  Are you still having problems?  If so, please post your MAT file somewhere I can take a look at and I'll see what I can do for you.  Thanks!

Yes, I'm still having problems. I've tried recreating the mission from scratch again, but no luck. MAT file: https://drive.google.com/file/d/1iWkzOhKvkuIBAvcAeVV802PU6dbGAmoK/view