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

[SpacedInvader]

12 minutes ago, Arrowstar said:

Probably an MCR bug, I've seen it before. Just kill them all and try again. :-) 

 

I can't even kill them, they are completely frozen.

Also, it keeps happening, even after several restarts.

Edited December 3, 2015 by SpacedInvader

[Arrowstar]

5 minutes ago, SpacedInvader said:

 

I can't even kill them, they are completely frozen.

Also, it keeps happening, even after several restarts.

Can you try reinstalling the MCR?

[SpacedInvader]

1 minute ago, Arrowstar said:

Can you try reinstalling the MCR?

I already tried an overwrite install, currently uninstalling / reinstalling.

[SpacedInvader]

Still no luck...

[SpacedInvader]

Hmm, seems like it may have been a conflict with ZoneAlarm firewall

[SpacedInvader]

Could someone please give me some guidance on how not to hit the Mun or Minmus on the way out of the Kerbin system?

I know the question sounds weird, but I'm having a lot of difficulty with this. I'm trying to send two missions to Duna during the same transfer window, but one of them has to get there a least a few days before the other because it is my remote tech network, which needs to be in place before the second mission as that one has a lot of complex maneuvers and I can't afford a communications blackout at an inopportune time. Anyway, here is the porkchop I'm working from:

If I just use the computed optimal date / time for departure, everything seems to go just fine, which is how I planned out the later mission, but no matter what date I choose from within that dark blue area using the select departure / arrival date, I always hit the Mun or Minmus and can never seem to get to Duna. I've tried manually adjusting the date, I've tried selecting a departure date and then letting the program find me an arrival date, I've tried setting the arrival date and letting the program find me a departure date, but no matter what I try, I always get the same result. I've currently run computations on 10 different departure / arrival dates and every last one of them has either impacted straight into one of the moons, or crossed an SoI and never makes it to Duna.

What am I doing wrong here?

[Drew Kerman]

22 hours ago, SpacedInvader said:

I'll give those a try, but I was hoping for a more direct approach than finagling... Do you think the flyby planner would be useful in this case?

Well I suppose instead of "finagling" I should have said "use the optimizer". It's not like you'll be flailing around in the dark, the optimizer can get you where you want to be

12 hours ago, SpacedInvader said:

Could someone please give me some guidance on how not to hit the Mun or Minmus on the way out of the Kerbin system?

What am I doing wrong here?

Could not reproduce a Mun encounter using the data from your screenshot (I'm set to Earth time). Initially the optimizer wouldn't hit Duna for me using a basic Minimize Distance to Body run but I took the 1055m/s prograde burn down to 1045m/s after looking in the system view with bodies toggled on and seeing my trajectory go high of Duna's and then I got a hit for Duna SOI.

[SpacedInvader]

I was able to find a departure that worked after about 15 tries, but it was pure luck. I think this is a user error rather than a program error though, as TOT seemed to work just fine, I was just feeding it departure dates that always had a moon in the way. The question going forward is whether or not there is a way to tell from looking at the porkchop plot which day combinations are going to have moons in the way. Are those small areas of higher dV that run diagonally through the plot indicative of this?

Also, again, can someone please tell me how to properly set up an aerobraking maneuver...

[Drew Kerman]

11 hours ago, SpacedInvader said:

I was able to find a departure that worked after about 15 tries, but it was pure luck. I think this is a user error rather than a program error though, as TOT seemed to work just fine, I was just feeding it departure dates that always had a moon in the way. The question going forward is whether or not there is a way to tell from looking at the porkchop plot which day combinations are going to have moons in the way. Are those small areas of higher dV that run diagonally through the plot indicative of this?

AFAIK there's nothing indicative from the plot that will tell you if a moon is in the way. I guess you just had bad luck. That result I shared was the first departure burn I tried. If you really want to make sure Mun isn't ever in your way, adjust your starting orbit inclination. I don't know how much would be good though. Really depends on how straight you shoot out of the system. Less of a parabola will need a higher inclination to pass over Mun's SOI

11 hours ago, SpacedInvader said:

Also, again, can someone please tell me how to properly set up an aerobraking maneuver...

I'll work up a Wiki entry on it later

Okay it's up. If you have any questions let me know.

Edited December 5, 2015 by Gaiiden

[SpacedInvader]

On 12/4/2015, 9:22:27, Gaiiden said:

AFAIK there's nothing indicative from the plot that will tell you if a moon is in the way. I guess you just had bad luck. That result I shared was the first departure burn I tried. If you really want to make sure Mun isn't ever in your way, adjust your starting orbit inclination. I don't know how much would be good though. Really depends on how straight you shoot out of the system. Less of a parabola will need a higher inclination to pass over Mun's SOI

I'll work up a Wiki entry on it later

Okay it's up. If you have any questions let me know.

 

Thanks, I've had a chance to read it and I can see where I was going wrong I think. I was placing the aerobrake maneuver at the periapse because I assumed it would be modeled as impulsive like dV maneuvers. Setting up a coast to prior to the atmosphere solved that issue at least. 

Now, a question: In the drag coefficient tooltip, it says that for FAR this is Cd * A, of which, Cd seems readily available, being listed right next to Cl on the data and stability derivatives page. A, on the other hand has me a little lost... is this referring to the "Ref Area" variable, or is there another "A" somewhere? That all said, is the FAR data an acceptable way of finding the drag coefficient, or should I really go out and run the calculator?

 

[Drew Kerman]

13 hours ago, SpacedInvader said:

Now, a question: In the drag coefficient tooltip, it says that for FAR this is Cd * A, of which, Cd seems readily available, being listed right next to Cl on the data and stability derivatives page.

Wait wait wat? Tooltip? A? I have not seen this 

I'll have to check later when I'm home. In the meantime it's the weekend so good chance @Arrowstar will happen by to answer. 

Might explain why my post linked at the top of the wiki entry had such erroneous results, since I'm using FAR

Edit: Ok I've looked into this and yea, this could explain a lot Arrowstar take that out of the tooltip and put it in the dialog window!! Although to be honest I don't know how I ever missed that. I use the keyboard a lot though (as Arrowstar learned when I bugged him to add Esc/Enter window closing, heh) instead of using my mouse to select things so that would be my best guess as to why I never saw it.

I'm going to plan another atmospheric dip with my Duna probe using this new information and see what happens.

Quote

A, on the other hand has me a little lost... is this referring to the "Ref Area" variable, or is there another "A" somewhere?

Yes, A is the reference area you can get in the FAR window

Quote

That all said, is the FAR data an acceptable way of finding the drag coefficient, or should I really go out and run the calculator?

I'm not sure. Arrowstar would have to answer this definitively but I would say no. From my recent check of all this stuff I see that the Cd readout that FAR gives is calculated in real time, which means it changes not just on your ship orientation but your altitude as well, especially in relation to the Reynolds number and I wouldn't know what value you should/could take from that. I think the Mission Architect calculations derive a more usable average number that it can apply for the coast through the entire atmosphere.

Edited December 7, 2015 by Gaiiden
great Jeb!!! how'd I miss that??

[SpacedInvader]

9 hours ago, Gaiiden said:

Wait wait wat? Tooltip? A? I have not seen this 

I'll have to check later when I'm home. In the meantime it's the weekend so good chance @Arrowstar will happen by to answer. 

Might explain why my post linked at the top of the wiki entry had such erroneous results, since I'm using FAR

Edit: Ok I've looked into this and yea, this could explain a lot Arrowstar take that out of the tooltip and put it in the dialog window!! Although to be honest I don't know how I ever missed that. I use the keyboard a lot though (as Arrowstar learned when I bugged him to add Esc/Enter window closing, heh) instead of using my mouse to select things so that would be my best guess as to why I never saw it.

I'm going to plan another atmospheric dip with my Duna probe using this new information and see what happens.

Yes, A is the reference area you can get in the FAR window

I'm not sure. Arrowstar would have to answer this definitively but I would say no. From my recent check of all this stuff I see that the Cd readout that FAR gives is calculated in real time, which means it changes not just on your ship orientation but your altitude as well, especially in relation to the Reynolds number and I wouldn't know what value you should/could take from that. I think the Mission Architect calculations derive a more usable average number that it can apply for the coast through the entire atmosphere.

I did a little testing and feel that something is not correct with the aerobraking calculations. Both KSPTOT and the online KSP aerobraking calculator state that 0.2 is a decent, though very rough, estimation of the coefficient of drag. Now, I've gone and run through the aerobraking calculator a couple of times and its given me different numbers based on two different periapse altitudes, but both seem WAY wrong. The first time through, I set my periapse at 50km with an apoapse of 1000km and the calculator gave me a Cd of 20.07. The second time through, I set the periapse at 60km with the same 1000km apoapse, and the resulting Cd was 24.30. Seems to me that these numbers should not be different?

Here's the funny thing, though, after getting these numbers, I replicated the maneuvers in the Mission Architect and was surprised to see that the resulting change in orbit did not match what was occurring in KSP. The first aerobrake, with a periapse of 50km predicted an apoapse of ~870km after the maneuver, while in KSP, it was actually ~691km. The second pass predicted an apoapse of 973km after the manuever, but was actually ~935. Now, I can understand that KSPTOT is really only a simulation and there are variables it can't account for easily (like periapse dropping during the braking maneuver), but it would seem to me that if I do the test braking for calculation, then immediately input the resulting Cd into an aerobraking maneuver within KSPTOT (basically the conditions which resulted in that Cd calculation in the first place), then the orbits should be the same in KSPTOT and KSP?

EDIT: The reason I'm trying to figure this out so intently is that I've already got missions on their way to Duna and Eve that are going to rely on accurate aerobraking to hopefully get encounters with their respective moons in addition to assisting in capture.

Edited December 7, 2015 by SpacedInvader

[Drew Kerman]

47 minutes ago, SpacedInvader said:

I did a little testing and feel that something is not correct with the aerobraking calculations. Both KSPTOT and the online KSP aerobraking calculator state that 0.2 is a decent, though very rough, estimation of the coefficient of drag. Now, I've gone and run through the aerobraking calculator a couple of times and its given me different numbers based on two different periapse altitudes, but both seem WAY wrong. The first time through, I set my periapse at 50km with an apoapse of 1000km and the calculator gave me a Cd of 20.07. The second time through, I set the periapse at 60km with the same 1000km apoapse, and the resulting Cd was 24.30. Seems to me that these numbers should not be different?

Here's the funny thing, though, after getting these numbers, I replicated the maneuvers in the Mission Architect and was surprised to see that the resulting change in orbit did not match what was occurring in KSP. The first aerobrake, with a periapse of 50km predicted an apoapse of ~870km after the maneuver, while in KSP, it was actually ~691km. The second pass predicted an apoapse of 973km after the manuever, but was actually ~935. Now, I can understand that KSPTOT is really only a simulation and there are variables it can't account for easily (like periapse dropping during the braking maneuver), but it would seem to me that if I do the test braking for calculation, then immediately input the resulting Cd into an aerobraking maneuver within KSPTOT (basically the conditions which resulted in that Cd calculation in the first place), then the orbits should be the same in KSPTOT and KSP?

EDIT: The reason I'm trying to figure this out so intently is that I've already got missions on their way to Duna and Eve that are going to rely on accurate aerobraking to hopefully get encounters with their respective moons in addition to assisting in capture.

That Cd is HUGE. But maybe your vessel is really big? I don't know what realistic limits for Cd are. You'll have to wait a day or two while I run my own tests around Duna and see how things go. Maybe I'll get to it later tonight. I'm actually planning it now.

I'm just dropping by to leave a note for @Arrowstar that the Aerobrake event dialog isn't non-modal like all the rest of the event state dialogs. You also can't change an aerobrake line color

oh, and Mission Architect does indeed account for your Pe dropping during an aerobrake. Look again at the last screenshot in the tutorial and notice how the Pe value changed from Event 1 to Event 3

Edited December 7, 2015 by Gaiiden

[SpacedInvader]

1 hour ago, Gaiiden said:

That Cd is HUGE. But maybe your vessel is really big? I don't know what realistic limits for Cd are. You'll have to wait a day or two while I run my own tests around Duna and see how things go. Maybe I'll get to it later tonight. I'm actually planning it now.

I'm just dropping by to leave a note for @Arrowstar that the Aerobrake event dialog isn't non-modal like all the rest of the event state dialogs. You also can't change an aerobrake line color

oh, and Mission Architect does indeed account for your Pe dropping during an aerobrake. Look again at the last screenshot in the tutorial and notice how the Pe value changed from Event 1 to Event 3

This is the craft:

The largest part is the 3.75m procedural heat shield on the bottom.

[Drew Kerman]

my initial testing run shows an improvement over my last one, instead of a +185km error (in actual Ap minus planned Ap) I got -34km, so now the modeling was too draggy. But I may have uncovered a bug in FAR I'm still waiting to hear back on that affects the calculations

Bummer no reply today. I will check back again tomorrow.

I see you lurking, Arrowstar

Edited December 10, 2015 by Gaiiden

[SpacedInvader]

On 12/8/2015, 4:37:47, Gaiiden said:

my initial testing run shows an improvement over my last one, instead of a +185km error (in actual Ap minus planned Ap) I got -34km, so now the modeling was too draggy. But I may have uncovered a bug in FAR I'm still waiting to hear back on that affects the calculations

Bummer no reply today. I will check back again tomorrow.

I see you lurking, Arrowstar

You may have trouble getting support on an old version. I know ferram has commented in the past that everyone should be updated if they want help because its not easy for him to keep track of all of the different versions. But I hope you get it sorted out.

[Arrowstar]

On 12/8/2015, 5:37:47, Gaiiden said:

I see you lurking, Arrowstar

Lol yes indeed.  Life has been very busy lately, I'll follow up more when I can...

[Drew Kerman]

9 hours ago, SpacedInvader said:

You may have trouble getting support on an old version. I know ferram has commented in the past that everyone should be updated if they want help because its not easy for him to keep track of all of the different versions. But I hope you get it sorted out.

It's a very easy thing to test. I was hoping someone set up with the latest version could at least tell me if they could/couldn't reproduce. Are you on the latest version?

4 hours ago, Arrowstar said:

Lol yes indeed.  Life has been very busy lately, I'll follow up more when I can...

No worries. Holidays (on top of whatever else). Ugh

Edited December 10, 2015 by Gaiiden

[SpacedInvader]

7 hours ago, Gaiiden said:

It's a very easy thing to test. I was hoping someone set up with the latest version could at least tell me if they could/couldn't reproduce. Are you on the latest version?

I am, I guess I could try replicating the issue when I get a chance tonight. What are the steps to replicate?

[Drew Kerman]

Load a craft. Note reference area. Go back to tracking station. Reload craft. See if ref area changed

like I said. Simple

[SpacedInvader]

Ok, finally had a chance to test and I'm getting the same behavior 0.75m prior to tracking station and 0.628m after.

[Drew Kerman]

cool thanks. Good to know its actually an issue.

@Arrowstar I can't have definitive results for my latest aerobrake test until I find out how much off the FAR value of A turns out to be. However I don't expect it to be a substantial amount or it probably would have been noticed before. I've plugged in both high and low numbers its given me and the diff is not enough to account for the roughly 50-30km inaccuracy. Then again I'm not sure what margin of accuracy users should be expecting with this. Have an idea? Or did I just give it to you?

Here is my mission file, along with the initial states you can load prior to the areobrake event - the actual orbit after Dip #1 is here and the actual orbit after Dip #2 is here (Ap & Pe are listed near the top of the data to the right of the craft image). Note I forgot to do a flight state save just prior to my first aerobrake pass, but I did for my second.

[Constan7ine]

So I have some questions, and a problem I'd like some help with.

Firstly, when using the porkchop plotter, what exactly is meant by "Earliest Arrival Time"? I don't see how it's a useful metric. If a mission was time critical you'd want something like "Latest Allowed Arrival Time", and it would find a trajectory within that time. As it is now I don't understand it. I'm not particularly bothered with how long the mission takes, I just want my path optimised to use the least Dv and leave at the earliest time that's reasonable. If I leave that earliest arrival time at 0 for a trip from Kerbin to Jool, the optimal path isn't optimal and uses 16 m/s, whereas pushing my earliest arrival time to a year ahead gives me better options. How then do I use this to find the lowest possible Dv within a reasonable time range? What specifically does that number mean.

Now onto my second issue. Actually first let me provide some context. I'm testing this with Kerbal X, on a stock solar system. The only mods I have are visual, or things like mechjeb and kerbal engineer. 

Anyway, After fiddling for a while I found a reasonable trajectory to Jool with the porkchop plotter. It looked like this:

 

Now I hit "Compute departure burn" and load in my orbit from KSP, (a 100km circular orbit) and it gives me this nice graph of a suitable burn to Jool:

I then right click on the DV maneuver window and upload to KSP. I get this in KSP:

This isn't even remotely correct. What went wrong? How do I make it work nicely?

Thanks for your help!

Edited December 14, 2015 by Constan7ine
More info

[Drew Kerman]

7 hours ago, Constan7ine said:

This isn't even remotely correct. What went wrong? How do I make it work nicely?

You're not supposed to take your departure burn straight into KSP. I would suggest reading through the tutorial PDF included with KSPTOT on getting to Laythe. That's the same basic guideline you need to get to any planet/moon in KSP and fortunately in your case getting to Laythe is a step further than getting to Jool.

Arrowstar will have to answer your other question

[Constan7ine]

5 hours ago, Gaiiden said:

You're not supposed to take your departure burn straight into KSP

So I read through and followed the instructions in the PDF manual, I did everything asked, except, my target body was Jool, so I optimised my mission to  fly to jool and not Laythe. I changed the final orbit periapse to be to appropriate for Jool, and otherwise I did everything as shown in the manual. I uploaded the first DV burn to KSP, and I get this:

EDIT: After experimenting with the uploaded node with Precise Node, I noticed that simply changing the time of the node by even a few minutes is vastly improving the trajectory, so much so I was able to get an encounter, by shifting the node 7 minutes forward. So for some reason KSPTOT is giving me a very slightly incorrect maneuver time.

Any idea why this might be the case?

Edited December 15, 2015 by Constan7ine
More info