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

[bk2w]

I'm puzzling over an orbital problem that I can't quite get a grip on. I'm trying to arrange a Kerbin-Eve-Moho journey, and I'm trying to arrange to have the Eve flyby happen at the right time so that I can use the Eve flyby to change inclination and insert me into the same orbital plane as Moho. This way I use the free dV of the flyby to make the expensive maneuver.

However, I can't figure out a good way of figuring out exactly when that flyby should happen.

I can get a rough estimate by eyeballing the crossing nodes in KSP and fast-forwarding time until I see Eve at the estimated node. Add in multiple of the sidereal orbit period, and I get a number of candidate times. Check the pork chop plot and I see that 15271920 seconds UT gives me a decently cheap transfer (2.6km/s) and has the Eve fly-by occurring near where I think the node is.

But when I plug the transfer into MA, and ask it to optimize the Kerbin ejection maneuver to get me Moho's inclination and RAAN, it can't manage it. I'll get the 7° inclination, but a 73° RAAN (as opposed to Moho's 70° RAAN).

So, how can I improve my estimate of the Eve-Moho nodes and when Eve will arrive at the nodes? Is there another way to approach the whole problem of finding the right fly-b maneuvers?

Mission Architect file can be found at https://www.dropbox.com/s/qxpzznnsupwzufb/Mission%20to%20Moho.mat?dl=0

-bk2w

[Drew Kerman]

So to be honest, I really don't like the MEA now that I have Mission Architect. I would say if you're looking to execute an impulsive maneuver in KSP, convert it to a finite duration maneuver by right clicking the mission script and selecting "convert impulsive maneuver" (when you have the correct maneuver highlighted). Then just execute that (if you upload a finite duration maneuver, the node is created at the start time). MA does everything MEA does but without the annoyances you pointed out above.

Interesting! I will give that a go

[Arrowstar]

I'm puzzling over an orbital problem that I can't quite get a grip on. I'm trying to arrange a Kerbin-Eve-Moho journey, and I'm trying to arrange to have the Eve flyby happen at the right time so that I can use the Eve flyby to change inclination and insert me into the same orbital plane as Moho. This way I use the free dV of the flyby to make the expensive maneuver.

However, I can't figure out a good way of figuring out exactly when that flyby should happen.

I can get a rough estimate by eyeballing the crossing nodes in KSP and fast-forwarding time until I see Eve at the estimated node. Add in multiple of the sidereal orbit period, and I get a number of candidate times. Check the pork chop plot and I see that 15271920 seconds UT gives me a decently cheap transfer (2.6km/s) and has the Eve fly-by occurring near where I think the node is.

But when I plug the transfer into MA, and ask it to optimize the Kerbin ejection maneuver to get me Moho's inclination and RAAN, it can't manage it. I'll get the 7° inclination, but a 73° RAAN (as opposed to Moho's 70° RAAN).

So, how can I improve my estimate of the Eve-Moho nodes and when Eve will arrive at the nodes? Is there another way to approach the whole problem of finding the right fly-b maneuvers?

Mission Architect file can be found at https://www.dropbox.com/s/qxpzznnsupwzufb/Mission%20to%20Moho.mat?dl=0

-bk2w

It's a bit unclear from your post. Have you tried using the flyby maneuver sequencer tool? This should, in theory, find a near-optimal flyby trajectory without you having to do all of this additional work.

[Drew Kerman]

So I tried the impulsive burn conversion and have an issue? I went 2x warp on rails, loaded orbital data from KSP, set up a circularize maneuver and checked what MA said my Ap/Pe would be - 494.123km. I changed it to proscribed and uploaded it to KSP and checked the Ap/Pe of the resulting maneuver - 494.122/494.125. Excellent. Then I converted to the finite duration and checked MA, which told me my Ap/Pe would be 495.29/492.938. When I loaded the maneuver into the game I checked the resulting plot in the map screen and it told me my Ap/Pe would be 497.333/490.911. Again, all this is on rails so the craft in the game isn't changing any of its orbital parameters. What gives?

[Arrowstar]

So I tried the impulsive burn conversion and have an issue? I went 2x warp on rails, loaded orbital data from KSP, set up a circularize maneuver and checked what MA said my Ap/Pe would be - 494.123km. I changed it to proscribed and uploaded it to KSP and checked the Ap/Pe of the resulting maneuver - 494.122/494.125. Excellent. Then I converted to the finite duration and checked MA, which told me my Ap/Pe would be 495.29/492.938. When I loaded the maneuver into the game I checked the resulting plot in the map screen and it told me my Ap/Pe would be 497.333/490.911. Again, all this is on rails so the craft in the game isn't changing any of its orbital parameters. What gives?

I'll let you answer your own question, actually. The maneuver you uploaded was modeled as a finite duration maneuver with the uploaded maneuver node in KSP placed at the start of that maneuver. Why would KSP's map view show a different post-maneuver orbit than Mission Architect?

[Drew Kerman]

I'll let you answer your own question, actually. The maneuver you uploaded was modeled as a finite duration maneuver with the uploaded maneuver node in KSP placed at the start of that maneuver. Why would KSP's map view show a different post-maneuver orbit than Mission Architect?

Oh, duh. Because KSP is assuming an instantaneous change in momentum. Yea, I totally missed that

[Arrowstar]

Gaiiden, can you let me know if this build resolves the issue you had with the mission animator?

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v121_prerelease1.zip

[Drew Kerman]

works a charm!

Looks like my Mun mission won't be able to do an aerobrake test coming home, due to complications. Would the MA aerobrake feature work for return trajectories or should I just head over to the Trajectories mod for that?

[wmvanvliet]

I have a fully functional MATLAB 2014b installation. Can I run KSP TOT from the source code directly? (maybe I can even help in development a bit, squash bugs when I find them). Tried running mainGUI, but it gives me errors.

[Arrowstar]

works a charm!

Looks like my Mun mission won't be able to do an aerobrake test coming home, due to complications. Would the MA aerobrake feature work for return trajectories or should I just head over to the Trajectories mod for that?

You should be able to use the MA aero code, but feel free to cross-check with Trajectories.

EDIT: Just as a heads up, I'll probably put out v1.2.1 today then, get the fixes to everyone else. Thanks for the help!

I have a fully functional MATLAB 2014b installation. Can I run KSP TOT from the source code directly? (maybe I can even help in development a bit, squash bugs when I find them). Tried running mainGUI, but it gives me errors.

You can run the code however you'd like, I suppose. You want to run projectMain.m, not mainGUI. However, I do recommend running the executable as it's known to work. Regardless, if you do find bugs, please report them to me here...

Edited February 14, 2015 by Arrowstar

[Snoman314]

And away I went! No need for any MAT file patching. Ahhh this feels good. I hate to admit it but that 2deg difference was really bugging me lol

Outstanding! Thanks for both your work persisting on fixing this.

[Arrowstar]

I'm happy to announce the release of v1.2.1:

• Fixes an issue with the rotation rate of Kerbin in the bodies.ini file.
  
• Fixes an issue with the way spacecraft are displayed in the Mission Animator.
  
• Fixes an issue with lat/long calculations.
  

Please let me know if you have any questions.

[Snoman314]

Hmm, the new version is giving me the following error when I try to run it. v1.2.0 seemed to be running fine before I tried v1.2.1

Edited February 15, 2015 by Snoman314

[Snoman314]

Hmm, the new version is giving me the following error when I try to run it. v1.2.0 seemed to be running fine before I tried v1.2.1

http://i.imgur.com/qqojNGT.png?1

Ok... Never mind, out of frustration I just tried running it again, and this time it worked. Weird...

[Arrowstar]

Ok... Never mind, out of frustration I just tried running it again, and this time it worked. Weird...

Old bug with MCR, never could figure what's going on. Can you make it happen again?

[Snoman314]

Old bug with MCR, never could figure what's going on. Can you make it happen again?

No sorry. It runs every time now. I didn't change anything either...

On a separate note, I'm hoping to get some help with something else. I'm having an issue with KSP and KSPTOT giving different outcomes. In the following google drive folder is my mission file, screenshots etc;

https://drive.google.com/folderview?id=0BxfgbiRB-sRrWG00VGZlSHdMQk0&usp=sharing

My KSP is pretty heavily modded, so I don't know if the persistence file will do you any good.

But here are the screenshots:

As you can see, the Mission Architect says that after the last burn, the vessel never returns to the Kerbin SOI. KSP itself disagrees. ...? Why?

I'm trying to fly a mission to Minmus, via the Sun's SOI in order to get a little more science and most of all, to get some extra XP to level up my Kerbonauts. I used the 'Show SOI radii' and 'Show children' etc buttons to guesstimate the appropriate ejection angle from Kerbin so that shortly after leaving the SOI, a burn back along my path (relative to Kerbin) sends me back within Kerbin's SOI in the vicinity of an encounter with Minmus. From the screenshot at the top right, you can see I pulled that off (the maneuver is timed for 600 seconds after leaving Kerbin's SOI). (BTW I did this by setting a circularise node (relative to the sun), then converting back to an orbital vector node, and doubling the values that came across).

My plan from here was to optimise just the last burn to generate an encounter with Minmus, as I think it's relatively close. However as I outlined above, KSPTOT isn't showing me as entering the SOI of Kerbin.

So... what now? Any ideas?

Edited February 15, 2015 by Snoman314
fixing image links

[Drew Kerman]

are you using Real Solar System as part of a visual enhancement mod?

[Arrowstar]

Snoman314: Can you duplicate the issue with stock KSP 0.90? That'll be the only way I can really figure out what's going on. Thanks for the info thus far though, it's good.

EDIT: Okay, so the issue is that you're having KSP TOT look for an SoI transition so close to the transition that just occurred (as compared to the size of the Sun's SoI, of course). MA's SoI transition finder really doesn't like doing things like that, it's mostly for safety (don't want to keep catching the same SoI transition multiple times in a row). I'll try to figure something out tomorrow, see if I can help it, though.

Edited February 15, 2015 by Arrowstar

[skykooler]

You can run the code however you'd like, I suppose. You want to run projectMain.m, not mainGUI. However, I do recommend running the executable as it's known to work. Regardless, if you do find bugs, please report them to me here...

Will 2014a work or does it have to be 2014b? The former is apparently available at my school.

[Snoman314]

are you using Real Solar System as part of a visual enhancement mod?

Nope. No RSS, and I uninstalled the visual enhancement mods a while back.

- - - Updated - - -

Snoman314: Can you duplicate the issue with stock KSP 0.90? That'll be the only way I can really figure out what's going on. Thanks for the info thus far though, it's good.

EDIT: Okay, so the issue is that you're having KSP TOT look for an SoI transition so close to the transition that just occurred (as compared to the size of the Sun's SoI, of course). MA's SoI transition finder really doesn't like doing things like that, it's mostly for safety (don't want to keep catching the same SoI transition multiple times in a row). I'll try to figure something out tomorrow, see if I can help it, though.

I can try with a stock install tomorrow, but the theory about it being too close to the previous transition does fit with what I was seeing. For example I can get it to work if the transition back to Kerbin's SOI is a week or so later, but when I get the maneuver right to minimise time outside the SOI, it doesn't work. I'll try setting a coast of a few hours manually and see what happens tomorrow.

Thanks!

[Arrowstar]

Will 2014a work or does it have to be 2014b? The former is apparently available at my school.

It has to be R2014b, sorry. You don't need MATLAB to run the program though, just the MCR, which I make available for download in the first post of this thread.

I can try with a stock install tomorrow, but the theory about it being too close to the previous transition does fit with what I was seeing. For example I can get it to work if the transition back to Kerbin's SOI is a week or so later, but when I get the maneuver right to minimise time outside the SOI, it doesn't work. I'll try setting a coast of a few hours manually and see what happens tomorrow.

Thanks!

Thanks, I will investigate more this afternoon.

[Snoman314]

OK, I've tried replacing the second coast to Next SOI Transition node with a 5 day 'Go to Delta Time' coast. According to the game, by that point I'd probably be back on my second escape trajectory. Not so according to KSP TOT:

I'm going to try a stock KSP later today. Will take a while to set up.

[Arrowstar]

OK, I've tried replacing the second coast to Next SOI Transition node with a 5 day 'Go to Delta Time' coast. According to the game, by that point I'd probably be back on my second escape trajectory. Not so according to KSP TOT:

http://i.imgur.com/3JOuFSX.png?1

I'm going to try a stock KSP later today. Will take a while to set up.

Actually, could you try this new build of KSP TOT? Let me know if it works for you.

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v122_prerelease1.zip

[bk2w]

It's a bit unclear from your post. Have you tried using the flyby maneuver sequencer tool? This should, in theory, find a near-optimal flyby trajectory without you having to do all of this additional work.

Okay, it turns out that a big part of my problem with the Flyby Tool is a bug in KSPTOT. Something isn't calculating the orbits correctly when TOT is set for Kerbin Time. The suggested burns and orbits simply don't work in KSP or MA, in addition to calling for large delta-V.

Earth-Time Flyby:

Kerbin-Time Flyby:

I've confirmed this behavior with the Windows 1.2.1 app.

Avoiding this bug helps me get good flyby sequences, and I can approximately control the flyby date by narrowly constraining the departure date. The Flyby tool ends up finding a sequence that passes Eve close to when I desire, and uses Eve to change into Moho's plane. Is there a way to constrain the Flyby tool to visit Eve at a particular time, and allow it to find the best departure date?

However, I still haven't figured out the more basic orbital question: how can I determine when one planetary body is crossing through the plane of a second planetary body?

-bk2w

Edited February 16, 2015 by bk2w

[Arrowstar]

Could the issue be that the definition of a day (in seconds) is different between the two? That would dictate how your flight time bounds (in units of days) are interpreted.

A Kerbin day is 21600 seconds, and an Earth day is 86400 seconds. Could this be the problem?

However, I still haven't figured out the more basic orbital question: how can I determine when one planetary body is crossing through the plane of a second planetary body?

Strictly speaking, you would have to compute the line of nodes between the bodies. This is a vector from the central body in the direction of the cross product of the two orbit normal vectors.The points at which that vector intersects the orbit are the ascending and descending nodes.

Edited February 17, 2015 by Arrowstar