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

[Drew Kerman]

new report has to do with these SFS files - they are all roughly the same, captured within 2hrs of each other, but for all of them even on the latest PR I couldn't get MA to show all the vessels that are actually in the file when trying to import orbital data

[Drew Kerman]

hrrmmmmm unless I'm somehow being incredibly dense there seems to be a problem with the Drag Coefficient Calculator:

It just locks up the program and never finishes computing. Same result if I select FAR modeling as well

[Drew Kerman]

yup, issue spam means I'm currently working on a mission! Here's a new one, found in PR2 but brought forward to PR6 and still the same symptoms. MAT file. Repro:

1. open Set State for Orbit 2
2. change any of the Mass properties
3. close and note Final State lists changes
4. re-open Set State for Orbit 2
5. note that fields have reset to default
6. cancel out to not save and have the bug revert values
7. insert a new Initial State at the end, alter any of the Mass values before saving
8. note Final State matches your mass values okay
9. re-open the Set State that was just created
10. note that the Mass values now match what was entered for the previous Set State event

So we have two issues here: unable to save proper mass values (which is bad when only needing to change orbital data, now you also have to make sure to set the Mass values too) and improper loading of mass values (maybe a feature actually to carry forward values?)

Fortunately, now that I understand the problem it's easy to work around

[Arrowstar]

On 1/29/2020 at 4:03 AM, Drew Kerman said:

yup, me again.

Tried to enable orbital decay and get an error. Repro is just load a default MA file, coast to TA of 0 with 1 rev and check the orbital decay use box.

Resolved for next release.

[Arrowstar]

On 2/5/2020 at 11:41 PM, Drew Kerman said:

yup, issue spam means I'm currently working on a mission! Here's a new one, found in PR2 but brought forward to PR6 and still the same symptoms. MAT file. Repro:

1. open Set State for Orbit 2
2. change any of the Mass properties
3. close and note Final State lists changes
4. re-open Set State for Orbit 2
5. note that fields have reset to default
6. cancel out to not save and have the bug revert values
7. insert a new Initial State at the end, alter any of the Mass values before saving
8. note Final State matches your mass values okay
9. re-open the Set State that was just created
10. note that the Mass values now match what was entered for the previous Set State event

So we have two issues here: unable to save proper mass values (which is bad when only needing to change orbital data, now you also have to make sure to set the Mass values too) and improper loading of mass values (maybe a feature actually to carry forward values?)

Fortunately, now that I understand the problem it's easy to work around

Issue also resolved for next release, as well as another bug I found along the way.

On 2/2/2020 at 8:25 PM, Drew Kerman said:

hrrmmmmm unless I'm somehow being incredibly dense there seems to be a problem with the Drag Coefficient Calculator:

It just locks up the program and never finishes computing. Same result if I select FAR modeling as well

It looks like the way you've got it set up is causing the code that runs the drag calculations to become "stiff", meaning that the differential equations take forever to solve.  I've made a change to the ODE solver function to something that handles stiff ODEs better, but it is still going to take some time to solve.  I'm not completely sure why, to be honest.  It could be the pretty high periapsis altitude means that there isn't a lot of variance on the trajectory when you change the drag coefficient.

EDIT: Yeah, with that it solved in a few minutes.  The answer I got was 3286.799992 though... lol.

Edited February 8, 2020 by Arrowstar

[Arrowstar]

@Drew Kerman, sorry I haven't had the chance to respond to your messages over the past week.  It's been a crazy few days.  I think I've addressed everything bug-related you've mentioned though and I'll post a pre-release today with the fixes.

And here it is: KSPTOT v1.6.5 pre-release 7

Change log:

• LVD: Added the ability to compute the gradient sparsity to the custom finite differences gradient method, which can improve optimization speed and accuracy in some situations.
• LVD: Added IPOPT to optimizer list.
• MA: Resolved issue with orbital decay on coast that was breaking it.
• Resolved two issues with MA drag coefficient calculator that would slow down the calculations in some instances.

Edited February 8, 2020 by Arrowstar

[Drew Kerman]

5 hours ago, Arrowstar said:

sorry I haven't had the chance to respond to your messages over the past week.  It's been a crazy few days.  I think I've addressed everything bug-related you've mentioned though and I'll post a pre-release today with the fixes

No worries, I found work arounds to all the issues and was not held up in any way I hope the stacking of reports doesn't stress you out, I'm just noting them as I go along and with a mission in progress there tends to be more of them

5 hours ago, Arrowstar said:

It could be the pretty high periapsis altitude means that there isn't a lot of variance on the trajectory when you change the drag coefficient

Nope, that's not it. I know because for this issue I've just been working out the Cd manually and you can see orbital change easily out to 6 significant digits I only match the post-aerobrake propagation Ap to the actual post-aerobrake Ap but it's been accurate enough that I haven't had trouble planning out maneuvers two orbits in advance. Alright so I tested my 68km pe on the new version and yea it's still getting stuck but at least now does so gracefully. Down to 64km and it's churning out some results in a few seconds. Wait I went back and tried a later pass at 68km and got a quick result. I don't have time to look into this more yet but I will at some point after the mission and pass along case files that work and don't work at 68km

Cygnus launch tomorrow! I'm making another trip since I caught it after dawn last time and this is just at sunset, plus I got a friend interested in coming now that I know how to do it - Wisharts Point was great

Edited February 9, 2020 by Drew Kerman

[Drew Kerman]

here's a strange one, possible edge case. MAT files. Start with #1

1. add a coast to ascending node
2. convert the AN coast to UT and back off 5min
3. add a coast to function value of 500km altitude (my comms range)
4. add a coast to Pe
5. add a coast to function value of 500km altitude
6. advance script to the Pe coast event
7. open the GA tool
8. check the option to display Pe crossings
9. plot and see Pe line displayed

Now repeat these steps for files #2 and #3. Both fail to show the Pe crossing. I upped the log entries to 5000 and 10000 and still got nothing displayed. It's not like the trajectory changed much between #1 and #2 or #3

[Drew Kerman]

On 1/28/2020 at 5:22 PM, Drew Kerman said:

how about shape selection options for the ground stations in addition to color? I have ground stations capable of reaching LKO and others for deep space, would like to visually distinguish the diff with shapes with colors for a second layer of denoting ranges

This wasn't bug related which is why I guess you didn't address it, but just wanted to make sure you saw it

On 1/29/2020 at 12:49 AM, Drew Kerman said:

sorry to stack things up but I'm going through the orbital plan of my mission and it seems the Comm Network Analysis tool does not take into account line of sight? Here are the relevant files. The network analysis results show that my first LOS will occur at 723s into the mission, however if I use the GA tool to plot line of sight to the Ockr station I get a dropout at 690s. if you plot distance, then I'm going out of comms range at 723s but by then I would have already lost signal due to horizon cutoff.

Also when you look at the map of my comm stations, why does the signal jump from Kongo->Arekibo->Kravass->KSC? That's zig-zagging. It should just be Kongo->Kravass->KSC (I realize this doesn't actually make any difference at the speed of light, and maybe that's the point - the relay code is expecting a much larger distance going from one probe in space to another not from ground station to ground station)

Finally, something funky with the X axis plotting for the Total Path Distance. Labeling is right but when I select the point over 5000 it's actually shown as 6200 in the data tip.

This was a bug I thought, but maybe I'm not understanding how the comm analysis tool is supposed to work?

On 2/2/2020 at 6:48 PM, Drew Kerman said:

new report has to do with these SFS files - they are all roughly the same, captured within 2hrs of each other, but for all of them even on the latest PR I couldn't get MA to show all the vessels that are actually in the file when trying to import orbital data

This was definitely a bug and still exists in the latest PR. In addition I have SFS files like this one where two craft are duplicated for some reason, with one of each in orbit around the sun, apparently

[Drew Kerman]

also just to be sure - elevation over the horizon GA output is saying 0° is the horizon and 90° is straight up correct? Anything below 0° is below the horizon?

[Arrowstar]

On 2/9/2020 at 1:34 AM, Drew Kerman said:

also just to be sure - elevation over the horizon GA output is saying 0° is the horizon and 90° is straight up correct? Anything below 0° is below the horizon?

Yes, this is true.

Thanks for reporting the other things.  I'll get to them when I have a free moment!

[stankwoo]

Working on a mission to do a free return from the Mun and basing it off of the example included. 

I setup the mission exactly as the example and optimize - everything looks great. Upload the two DV maneuvers (trans Mun and circularize upon return). The two maneuvers play out perfectly on the map - burn to Mun for a 60KM Mun Pe and then sling shot around for a Kerbin Pe of 80KM where I then circularize. 

Next steps:

1. Set alarm on Kerbal Alarm Clock for first maneuver node. Warp to that time.

2. Check the nodes in map and still looks good.

3. Burn for first maneuver node to head to the Mun.

4. After burn, check my map and maneuver nodes. The Mun PE is changed (from 60KM to 52KM roughly) and the Kerbin return PE is changed to 160KM. 

I am trying to understand why the results of the maneuver nodes changed after I did the executed the first maneuver node. Was it time warping or something I am completely missing? My goal is to completely plan the mission so if I need to break it up into parts or something similar please let me know.

Thanks!

MAT file: https://easyupload.io/7rjlq3

 

[Drew Kerman]

2 hours ago, stankwoo said:

I am trying to understand why the results of the maneuver nodes changed after I did the executed the first maneuver node. Was it time warping or something I am completely missing? My goal is to completely plan the mission so if I need to break it up into parts or something similar please let me know.

hard to say why you ended up the way you did without more details of how you actually executed the burn. No burn is perfect and no plan should be expected to work exactly as designed from start to finish. You will generally want to advance the mission script as you move along and re-optimize after every maneuver to get back on track.

[stankwoo]

@Drew Kerman thanks for the input. I just uploaded the maneuver and then executed it with Mechjeb just to make sure I was getting as close as possible in terms of accuracy. What are some other factors I should look out for?

Interesting about advancing the mission script as you move along. What kind of sequence would it be? 

1. Upload first maneuver and burn. 

2. Next stage in mission is a "Coast" specifically coasting to Mun Pe. It isn't perfect but I am content so I do not bother with any corrections.

3. Next stage in mission is a "Coast" specifically coasting to Kerbin Pe on the return from around the Mun. I see that my Kerbin Pe is not what I originally had planned in the MA. Do I need to insert a dV maneuver? Also how do I input my current position, etc. for the MA?

[Drew Kerman]

2 hours ago, stankwoo said:

I just uploaded the maneuver and then executed it with Mechjeb just to make sure I was getting as close as possible in terms of accuracy. What are some other factors I should look out for?

never used MechJeb but hear it's pretty good, so if that wasn't it you may have setup your vessel slightly wrong in MA, whether it be dry mass, wet mass, thrust, ISP, etc. Double check all your numbers. I've made plenty of stupid oversights in the past. Still do in the present. Triple check your numbers. Make sure the right thruster is assigned to your Dv maneuvers

above all just don't try to be perfect. no actual space mission does perfect. They like to say they are flying perfectly as planned but in reality they are just within acceptable margins that were decided ahead of time @Arrowstar feel free to smack me down here

2 hours ago, stankwoo said:

What kind of sequence would it be? 

Right-click on any event to "Advance Script" to that event. That will create a new Initial State at the top of the list with the orbital data MA expects you to have at that point in the mission. Double-click to edit it, right-click over the orbital properties and choose a method to import the actual orbital data from KSP. Then re-plan the rest of your mission as necessary. Repeat until mission concludes

Edited February 13, 2020 by Drew Kerman

[stankwoo]

Appreciate all the help.

One thing I did forget to do was on the "initial state" was upload my dry mass, fuel/ox, etc. I also went to each of the DVs nodes and made sure to select the correct thruster and verify the information was correct.

Still having the same issue where once I perform the first burn the second maneuver, etc. aren't matching up with MA. 

I'll keep playing with it to see if I can understand why.

[Arrowstar]

On 2/12/2020 at 8:15 PM, Drew Kerman said:

above all just don't try to be perfect. no actual space mission does perfect. They like to say they are flying perfectly as planned but in reality they are just within acceptable margins that were decided ahead of time @Arrowstar feel free to smack me down here

Correct!  And sometimes not within acceptable margins lol (though we have plans for that sort of thing).

23 hours ago, stankwoo said:

Still having the same issue where once I perform the first burn the second maneuver, etc. aren't matching up with MA.

How far off are you?

[Drew Kerman]

3 hours ago, Arrowstar said:

though we have plans for that sort of thing

sheeet you guys have plans for all sorts of things, I know it For this recent mission, there were things that went wrong where I was like "crap why didn't I think of that maybe happening?!" and it made me realize I was like dealing with 0.005% of what real mission planners have to worry about and at that point my brain almost melted (although, I'm not really too hard on myself cause I know these missions have teams of people putting their heads together)

[Arrowstar]

On 2/14/2020 at 1:55 AM, Drew Kerman said:

sheeet you guys have plans for all sorts of things, I know it For this recent mission, there were things that went wrong where I was like "crap why didn't I think of that maybe happening?!" and it made me realize I was like dealing with 0.005% of what real mission planners have to worry about and at that point my brain almost melted (although, I'm not really too hard on myself cause I know these missions have teams of people putting their heads together)

It's why we spend years on mission design.  We can't just YOLO our trajectories like people do in KSP.

[stankwoo]

On 2/13/2020 at 9:59 PM, Arrowstar said:

Correct!  And sometimes not within acceptable margins lol (though we have plans for that sort of thing).

How far off are you?

Before the first maneuver which is the mun injection, it says my second maneuver to circularize after return from Mun will put me at 75KM around Kerbin. After the burn the Pe goes to 156,213KM.

[Arrowstar]

On 1/28/2020 at 4:22 PM, Drew Kerman said:

@Arrowstar how about shape selection options for the ground stations in addition to color? I have ground stations capable of reaching LKO and others for deep space, would like to visually distinguish the diff with shapes with colors for a second layer of denoting ranges

Where?  Mission Animator?

[Arrowstar]

On 2/2/2020 at 5:48 PM, Drew Kerman said:

new report has to do with these SFS files - they are all roughly the same, captured within 2hrs of each other, but for all of them even on the latest PR I couldn't get MA to show all the vessels that are actually in the file when trying to import orbital data

Is what's missing asteroids or actual vessels?  Can you give me an example of a vessel missing in one of those files?

Edited February 16, 2020 by Arrowstar

[Drew Kerman]

19 hours ago, Arrowstar said:

It's why we spend years on mission design

I read the book on New Horizons and the Principle Investigator twitter hashtag has been very insightful.

10 hours ago, Arrowstar said:

Where?  Mission Animator?

yes. the shape option would be in the ground stations dialog but show up in Mission Animator

9 hours ago, Arrowstar said:

Is what's missing asteroids or actual vessels?  Can you give me an example of a vessel missing in one of those files?

It's not picking up the Kerbin I vessel

[Drew Kerman]

@Arrowstar heads up, my upcoming mission will be exposing KSPTOT a good deal over the next several days so be sure to check it out and let me know what you think. Tell any co-workers/friends you think might also be interested! @KSA_MissionCtrl - if anyone is really against visiting or following twitter the next best place is via the Ops Tracker since the tweets load on the side with 0-30s delay

[Arrowstar]

On 2/18/2020 at 7:53 AM, Drew Kerman said:

@Arrowstar heads up, my upcoming mission will be exposing KSPTOT a good deal over the next several days so be sure to check it out and let me know what you think. Tell any co-workers/friends you think might also be interested! @KSA_MissionCtrl - if anyone is really against visiting or following twitter the next best place is via the Ops Tracker since the tweets load on the side with 0-30s delay

Thanks for the visibility!  Sorry I haven't been able to code as much over the past few weeks, personal life has been crazy.