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

[Arrowstar]

5 hours ago, LGrim said:

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

I had to request access to this file because it doesn't look like it was shared properly.

[LGrim]

15 hours ago, Arrowstar said:

I had to request access to this file because it doesn't look like it was shared properly.

Sorry, I've fixed it now.

[Arrowstar]

I spent a bit of time today adding a few features to the next pre-release that I've been thinking about.  Included in KSPTOT 1.5.10 pre-release 10, these include:

• Mission Architect: Two new graphical analysis tasks and constraints, the hyperbolic excess velocity vector right ascension and declination angles.
• Mission Architect: The Optimizer observation window is now more useful.  The top plot showing variable values has been changed such that it plots from lower bound to upper bound of every value.  This means that extra large variable values (like times) will not completely wash out the plot anymore.
• MFMS: The number of decimal places in the output window has increased to 4 for each united value.
• Mission Architect: Tweaks to the options fed into the fmincon optimizer algorithm.
• Mission Architect: Included a new example case file: Kerbin-Eve-Jool-Eeloo mission.

Please let me know if you have any questions!

14 hours ago, LGrim said:

Sorry, I've fixed it now.

Thanks.  I'll take a look at this tomorrow.  In the mean time, go ahead and grab the pre-release I linked to in this post.  Use it to open the included MAT file in the pre-release ZIP file.  This is my take on the K-E-J-E mission you were talking about.  Word of warning: this mission took me most of today to complete.  It's a very hard case, even for a professional such as myself. It's not super surprising that you're having a bit of trouble, but keep at it and I'm sure you'll get it.  A few tips:

1. My process flow went something like this.  When starting, use the hyperbolic velocity R.A., Declination, and magnitude constraints in the mission optimizer.  Get the values for these from MFMS.  Don't try to target either the Kerbin outbound orbit or the Sun-centered orbit directly, it won't work well.  Allow the true anomaly of the burn and the three burn vectors to vary.  After you achieve those constraints, then turn them off and add a Coast to Sun SoI event (go to next SoI) and then a Coast to Periapsis with 1 rev before it.  Set the reference body to your target body.  Optimize again, setting your objective function to distance to your target body at that "coast to periapsis" event.  Once you've hit the target body's SoI and the periapsis of the inbound orbit is reasonably low, add a new set of constraints for the next set of hyperbolic velocity R.A., Declination, and magnitude constraints.  Optimize to achieve these, maximizing total spacecraft mass.  Be sure to insert a burn at the flyby periapsis and allow it's vector components to vary to hit the new constraints.
2. Mid-course correction maneuvers are critical.  It's just not going to happen that you're going to get Mission Architect to hit the flyby spot on without more parameters to vary.  In between each flyby, add a coast to some true anomaly that doesn't go past the next waypoint body and then a burn.  Look at what I did in the mission MAT file I put in the latest pre-release ZIP file (link above).
3. Keep your bounds on your variables, especially your burn vector components, wide open to start. +/- 1000 m/s is probably fine for each.  Go bigger if you need to.
4. Once you're reasonably happy with how a leg of a transfer looks, turn off the variables before and during it.  The more variables Mission Architect tries to optimize at once, the worse it's probably going to work.
5. Your two best friend objective functions are "minimize distance to body" and then "maximize mass".  Use the first to get into the SoI of each waypoint body and then the latter to help find the best transfer to that body.
6. Stick with impulsive maneuvers for now.  Finite burns will just make life harder.
7. Keep practicing!

EDIT: I just took a look at the MAT file you provided.  I'm guessing your issue is that you haven't set the appropriate event (event 5) and the appropriate body (Eve) next to the objective function selection in the Mission Optimizer window.  I did this and I got an Eve encounter on the first try.  Give that a whirl and see how it goes.

Edited June 17, 2018 by Arrowstar

[Drew Kerman]

On 6/12/2018 at 6:33 PM, Arrowstar said:

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.

Looks good on my end, actually! I will of course let you know if anything else pops up related to this

[Arrowstar]

53 minutes ago, Drew Kerman said:

Looks good on my end, actually! I will of course let you know if anything else pops up related to this

Glad to hear it.  If you have any other issues, let me know.

[Arrowstar]

By the way, @Drew Kerman and others, please let me know if you find any bugs in the latest pre-release version.  Otherwise I think I'm going to use that as the 1.5.10 release either later this week or this weekend.  Thanks! 

[LGrim]

On 6/17/2018 at 3:24 AM, Arrowstar said:

EDIT: I just took a look at the MAT file you provided.  I'm guessing your issue is that you haven't set the appropriate event (event 5) and the appropriate body (Eve) next to the objective function selection in the Mission Optimizer window.  I did this and I got an Eve encounter on the first try.  Give that a whirl and see how it goes.

I don't have problems getting encounters with Eve, that part is simple enough. I just can't seem to satisfy constraints. I've made sure that I select all the correct event and body before running the optimiser, but it still doesn't seem to work. I've documented what I do when I optimised the encounter with screenshots, so maybe that will help you identify what I'm doing wrong. It's here: https://imgur.com/a/bI0O067

I tried to start from scratch (again) and tried to use the tips that you gave in your reply. I couldn't even get through step 1. I followed the instructions provided, but it just couldn't satisfy the hyperbolic velocity R.A., declination, or magnitude constraints. Again, it was way off what I see the bounds to be. I probably made a mistake somewhere, but I don't understand where. Here is the file for that: https://drive.google.com/file/d/1z0JfEJ3Z1MN6T916YSw6plDB36onPQ2l/view?usp=sharing

Edited June 18, 2018 by LGrim

[Arrowstar]

1 hour ago, LGrim said:

I don't have problems getting encounters with Eve, that part is simple enough. I just can't seem to satisfy constraints. I've made sure that I select all the correct event and body before running the optimiser, but it still doesn't seem to work. I've documented what I do when I optimised the encounter with screenshots, so maybe that will help you identify what I'm doing wrong. It's here: https://imgur.com/a/bI0O067

I tried to start from scratch (again) and tried to use the tips that you gave in your reply. I couldn't even get through step 1. I followed the instructions provided, but it just couldn't satisfy the hyperbolic velocity R.A., declination, or magnitude constraints. Again, it was way off what I see the bounds to be. I probably made a mistake somewhere, but I don't understand where. Here is the file for that: https://drive.google.com/file/d/1z0JfEJ3Z1MN6T916YSw6plDB36onPQ2l/view?usp=sharing

Okay, I had a look.  The images were very helpful, thank you.  Without the actual mission plan you're trying to reproduce it's hard to help for sure, but I have some thoughts:

1. Drop the UT constraint for the time being.  It's probably just making things harder than they need to be at the moment.  Add it in later if you need to.
2. The three constraints you want to use for this flyby are the same you used to depart from Kerbin: hyperbolic excess RA, Declination, and velocity magnitude.  These should be easier to hit than the three orbital angles, or at least they were for me.  You'll get these numbers out of the outbound hyperbolic orbit section of MFMS, same as with the angles you were using.  Keeping the Central Body constraint isn't a bad idea either.
3. Your difficulties are definitely just a problem with the way the problem is posed, not your hardware or anything like that.  Try changing these things that I mentioned and then give it another go.  Also look at the MAT file I included in the latest pre-release ZIP file.  There should be some hints in there as to what I did with constraints and whatnot.

If you still have the MFMS data you're using to put together this mission plan and can give it to me (just paste it into this thread as a quote I suppose), that would help me help you recreate it better.

Good luck!  Let me know if I can help more.

[Drew Kerman]

9 hours ago, Arrowstar said:

please let me know if you find any bugs in the latest pre-release version

I just remembered there was an issue in the MFMS where the time constraints I was using between Urlum and Neidon were causing an error ping and a log entry. I just checked and I never saved the error log. Derp. I should be able to recreate it tho since I still have the numbers to work from - I have a 500 sequence run going on before I remembered so will check it out later tonight or tomorrow. Just leaving this here in case I forget somehow. Ping me by Wed if I don't get back to you on it by then

[Drew Kerman]

@Arrowstar first try! Here is the error log and bodies file, and here are the repro steps:

1. Open MFMS
2. Launch window open: 94608000
3. Launch window close: 126144000
4. # of runs: 500
5. Min CB Pe height: 3157882.971
6. Mission duration: 3650
7. Waypoints: Kerbin->Duna->Dres->Sarnus->Urlum->Neidon
8. Kerbin->Duna bounds (hi/low): 37/150
9. Duna->Dres bounds: 68/274
10. Dres->Sarnus bounds: 313/1252
11. Sarnus->Urlum bounds: 1772/7090
12. Urlum->Neidon bounds: 3382/13530
13. Press compute button
14. Error ding after 2-3 seconds

Anything above 1460 for lower bounds on Urlum->Neidon will not run. Number of runs doesn't seem to matter. I also recall this was an issue for routes not as extensive as this one, but that also ended with Urlum->Neidon transfer

Edited June 19, 2018 by Drew Kerman

[Arrowstar]

14 minutes ago, Drew Kerman said:

@Arrowstar first try! Here is the error log and bodies file, and here are the repro steps:

1. Open MFMS
2. Launch window open: 94608000
3. Launch window close: 126144000
4. # of runs: 500
5. Min CB Pe height: 3157882.971
6. Mission duration: 3650
7. Waypoints: Kerbin->Duna->Dres->Sarnus->Urlum->Neidon
8. Kerbin->Duna bounds (hi/low): 37/150
9. Duna->Dres bounds: 68/274
10. Dres->Sarnus bounds: 313/1252
11. Sarnus->Urlum bounds: 1772/7090
12. Urlum->Neidon bounds: 3382/13530
13. Press compute button
14. Error ding after 2-3 seconds

Anything above 1460 for lower bounds on Urlum->Neidon will not run. Number of runs doesn't seem to matter. I also recall this was an issue for routes not as extensive as this one, but that also ended with Urlum->Neidon transfer

Thanks.  I know what the issue is now, just some missed error handling on my part.  I need to think about how to fix it, but it won't be hard.  I'll try to get to it tomorrow.  In the mean time, the actual issue is that your max mission duration constraint is too small.  The genetic algorithm code is returning with a "unable to find a feasible starting point" error immediately.  In the mean time, try loosening this constraint up a bit.  I doubled what you provided and things ran just fine.  In fact, while I can improve my error handling a bit,  you'll need to change that constraint some before the optimizer will run regardless of what I do.

Thanks for finding this!

[Drew Kerman]

2 minutes ago, Arrowstar said:

In the mean time, the actual issue is that your max mission duration constraint is too small

oh DUH Yea an informative error message would do the trick, since this is really more of a user error not a program error

6 minutes ago, Arrowstar said:

In the mean time, try loosening this constraint up a bit.

Well no, because I want the mission to not exceed 10 years. The program is doing what I told it to do it just wasn't doing a good job of telling me I mean I ended up changing the Urlum->Neidon transfer duration anyways back when I had this issue a few weeks ago to get the thing to run, I just didn't understand why that worked, is all

[Arrowstar]

20 hours ago, Drew Kerman said:

oh DUH Yea an informative error message would do the trick, since this is really more of a user error not a program error

Well no, because I want the mission to not exceed 10 years. The program is doing what I told it to do it just wasn't doing a good job of telling me I mean I ended up changing the Urlum->Neidon transfer duration anyways back when I had this issue a few weeks ago to get the thing to run, I just didn't understand why that worked, is all

Got it.  Here's KSPTOT v1.5.10 pre-release 11, it includes:

• An error message when the MFMS optimizer returns abnormally, with a particular suggestion to check the waypoint flight time and maximum mission duration constraints.

Let me know if this takes care of the issue for you, it seems to be for me.  Thanks!

Unless other bugs are found, this will be the v1.5.10 release version, I think.

[Drew Kerman]

@Arrowstar is the new SOI search tolerance what I would tweak to make the SOI encounter time more accurate? I'm just concerned that if it's going to be a few seconds off then that will build up over several encounters to become rather inaccurate

[Arrowstar]

3 minutes ago, Drew Kerman said:

@Arrowstar is the new SOI search tolerance what I would tweak to make the SOI encounter time more accurate? I'm just concerned that if it's going to be a few seconds off then that will build up over several encounters to become rather inaccurate

Yes.  However, there is a bit more to it. 

Through extensive testing, I had previously found found that if I targeted the exact edge of the SoI , I would often get flip-flopping back and forth between SoIs because the SoI transition code only looks at location relative to nearby SoIs, and any numerical inaccuracy in the calculation of the transition would become very obvious.  In order to combat this, the target code actually targets a point about 1 km inside the SoI for descending SoI transitions (from planet to moons, for example).  This prevents that dithering back and forth.  It does also mean, though, that you'll probably be a few seconds off for each SoI transition.  But, because at such ranges from the planet's body the new body doesn't have much of an effect on the orbit, the trajectory should remain basically the same as if you were to target the SoI radius exactly.  In other words, the time from one SoI to another will be slightly different (though seconds in the course of days or years is really nothing), but it shouldn't impact the orbit or delta-v requirements.

Does that make sense?  It's a bit convoluted, I know.

[Drew Kerman]

sounds good, thanks as always for taking the time to explain

[Arrowstar]

19 hours ago, Drew Kerman said:

sounds good, thanks as always for taking the time to explain

So... I had a shower thought last night after I typed out my reply to you.  I didn't want to go speculating here until I tried it out, but now that I have, I think it will work.  Yesterday I mentioned SoI dithering.  This is when the code that finds and executes SoI transitions rapidly switches from a higher SoI to a lower one and back again without the spacecraft actually moving in space.  It always happens at the SoI boundary and can lead to infinite loops in the code actually.  This was the reason for having that 1-2 km pad in the SoI transition code: if the spacecraft was safely inside the SoI, then it wouldn't go looking for an upwards transition that shouldn't occur.

I realized that this is inelegant, however, after explaining it to you, and I did some thinking.  Basically, when there is a downwards transition, at the moment of transition, the new spacecraft state (in the lower SoI) must have a flight path angle that is negative, which is equivalent to a true anomaly between -180 degrees and 0 degrees.  The spacecraft must be descending, in other words.  (I actually use a slightly different test, a dot product between the position and velocity vectors, but it's the same thing.)  Likewise, at an upwards transition, immediately before the SoI transition, the spacecraft in the lower SoI must have a flight path angle that is positive - the spacecraft must be ascending.

So, what I've done tonight is set that "safety factor" distance to 0.0 km in my code, and then add these two tests at each SoI transition that is found.  The effect is that SoI transitions now occur immediately at the SoI boundary and not 1-2 km inside in for downwards transitions.  (Upwards transitions are unaffected since those could be computed exactly without numerical search algorithms.)  The SoI transition times should be anywhere from 0 to maybe 5 seconds more precise.  In most cases this really didn't alter any of my test cases, but in one it actually did disrupt the last leg of the trip such that I had to go reoptimize to re-find Duna's SoI again.  So maybe it was important, lol. 

Anyway, this new code is in KSPTOT v1.5.10 pre-release 12.  The changes here are:

• Update to the SoI transition search code that should now precisely find the SoI boundary for downwards transitions.
• Fixed a bug with the optimizer constraint warning message units.

@Drew Kerman (and anyone else interested!), could you take a look at some of your existing missions or asteroid cases with this new build and see if it helps the SoI transition times you've been documenting?  Would definitely appreciate it.

[Drew Kerman]

Shower thoughts FTMFW

11 minutes ago, Arrowstar said:

could you take a look at some of your existing missions or asteroid cases with this new build and see if it helps the SoI transition times you've been documenting?

Using the dates I posted my reports of the SOIs being off I was able to grab the proper save files from my backup service for those times and also had the saved orbital data from then too. Compared the SOI UT calculated by KSPTOT to what the game was showing for an SOI intercept and they matched to the second.

Three cheers for Arrowstar!!

[Arrowstar]

6 minutes ago, Drew Kerman said:

Shower thoughts FTMFW

Using the dates I posted my reports of the SOIs being off I was able to grab the proper save files from my backup service for those times and also had the saved orbital data from then too. Compared the SOI UT calculated by KSPTOT to what the game was showing for an SOI intercept and they matched to the second.

Three cheers for Arrowstar!!

Sweet!  This is excellent to hear! I'm glad it worked well.  So the times are within 1 second of KSP itself?

[Drew Kerman]

1 hour ago, Arrowstar said:

Sweet!  This is excellent to hear! I'm glad it worked well.  So the times are within 1 second of KSP itself?

Yes. In both test cases the time to SOI intercept given by Kerbal Alarm Clock was exactly the same as the time converted from UT copied out of KSPTOT for the intercept event

[Arrowstar]

1 minute ago, Drew Kerman said:

Yes. In both test cases the time to SOI intercept given by Kerbal Alarm Clock was exactly the same as the time converted from UT copied out of KSPTOT for the intercept event

Hah, perfect.  That's wonderful.  This is actually very interesting for me, because it demonstrates something I was never entirely sure about myself: that KSP is clearly using a similar technique that I am to find SoI transitions.  I suspect that they're doing something to keep the CPU time of the calculations down (whereas I just do what I need to do), but I suspect it's fundamentally the same approach.  Very cool.

Thanks for the verification tonight!

[LGrim]

I think I found a bug when setting the initial state in Mission Architect. I was setting the initial values for my orbit around Kerbin. I put in the following values:

Epoch =                                   0

Semi-major Axis =                    672 km

Eccentricity =                            0

Inclination =                    10.205 deg

Right Ascension of AN =         107.741 deg

Argument of Periapse =          172.740 deg

Real Anomaly =                            1

And when I save and close the window, it plays an error sound and changes the Arg of Peri and Real Anomaly Values. For some reason, it adds up the Arg of Peri to the Real Anomaly value and then sets the Arg of Peri value to 0. I've done a little bit of testing and it only seems to affect some values. I've reinstalled the prerelease and the issue is still there. Interestingly, I tested this in 1.5.9, and the issue is also there.

[Arrowstar]

3 hours ago, LGrim said:

I think I found a bug when setting the initial state in Mission Architect. I was setting the initial values for my orbit around Kerbin. I put in the following values:

Epoch =                                   0

Semi-major Axis =                    672 km

Eccentricity =                            0

Inclination =                    10.205 deg

Right Ascension of AN =         107.741 deg

Argument of Periapse =          172.740 deg

Real Anomaly =                            1

And when I save and close the window, it plays an error sound and changes the Arg of Peri and Real Anomaly Values. For some reason, it adds up the Arg of Peri to the Real Anomaly value and then sets the Arg of Peri value to 0. I've done a little bit of testing and it only seems to affect some values. I've reinstalled the prerelease and the issue is still there. Interestingly, I tested this in 1.5.9, and the issue is also there.

Thanks for the report.  I couldn't reproduce the "beep" error sound you found, but if you can post your ksptot.log file for me, and provide your MAT file that showed the error, I can investigate.

As far as the argument of perigee value changing, that is expected.  Your orbit is circular, and so argument of perigee is undefined because there is no perigee.  KSPTOT recognizes this and transforms your state representation into something that won't cause problems in the future by zeroing out that element of the state.  This error avoidance transformation is what you're seeing.  It's not a problem, it is a good thing.

For your interest, the relevant KSPTOT code.  The line "arg = 0" is the part that's doing what you're seeing.

    %%%%%%%%%%
    % Special Case: Circular Inclined
    %%%%%%%%%%
    if(ecc < 1E-10 && inc >= 1E-10 && abs(inc-pi) >= 1E-10)
        u = real(acos(complex(dotARH(nVect,rVect)/(norm(nVect)*norm(rVect)))));
        if(rVect(3) < 0)
            u = 2*pi - u;
        end
        tru = u;

        arg = 0;
    end

 

[Gordon Dry]

I'm not sure if this is intended to be used with additional planets.

Yes, I created a new bodies.ini just a couple of minutes ago out of the actual session in flight mode.

I want to go to Urlum - I also want to go there as quick as possible, so I entered 8 km/s to be taken into account for the calculation incl. capture burn.

I have set "Get orbit from KSP (Active vessel)" of course.
Same for UT.

I uploaded the manuever to the connected vessel.

 

I get this:

Ingame:

5years <> 14 years, totally something else ...

Where do I start to use this software the correct way?

2nd approach, when I don't "optimize" anything to get there quicker, I get these:

[ThreePounds]

13 minutes ago, Gordon Dry said:

I uploaded the manuever to the connected vessel.

I think you're supposed to take the information given in the departure information and take them to the mission architect to do some proper optimization on them before you can upload them to your game.