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

[Drew Kerman]

Also, found this "Documentation of KSP Physics" in the tutorials section and wondered if it would be of any help for anything. It does mention Lat/Lon conversions

[bk2w]

So I'm trying to plan a tricky maneuver using Mission Architect, and I'm not figuring things out quite right. I'd appreciate any help.

I have a craft in Kerbin orbit (and can get state from the SFS, no problem). I departing Kerbin and transferring to Jool with a low Pe over Jool (~8000km radius). Somewhere near the Jool Pe (maybe before, maybe after), I'll make another burn to adjust my swing around Jool and intercept Pol. Unfortunately, while I can work up a mission that gets me an 8000km periapsis and very little inclination, I can't seem to find the Pol intercept. The optimizer ends up halting with a Pol-periapsis of 50Mm, or 100Mm.

Using a fake orbit (prior to launching the actual spacecraft), I was able to find a mission that got my into an equatorial Pol orbit for about 3300m/s (1950m/s to transfer to Jool, 350m/s to intercept Pol, and 1000m/s to capture in Pol orbit). But reloading with the actual orbit shifts things enough that I can't locate any solution anymore.

A couple of runs with the Graphical Analyzer have suggested that Pol is basically on the wrong side of Jool when I make the fly-by. If I know where Pol is when I swing by Jool, I can advance or delay my Kerbin departure to compensate and place Pol in the right section of its orbit. But I can't quite determine where Pol IS when I fly-by.

Is there some way of determining where Pol is in relation to my spacecraft at the fly-by? Some other way of laying up the mission that can allow the optimizer to find a feasible solution?

-Brian

[ANWRocketMan]

@bk2w: Are you sure you have the correct orbital parameters? Thus the right RAAN, Inclination etc.? And that you're burning at the correct UT? UT especially could do you in.

@Arrowstar: One last question. How can I determine the burn parameters for a fly-by mission where I'm using a much shorter transfer time from the porkchop plotter for fly-by's? The Multi fly-by maneuver sequencer does not seem to acknowledge my bounds on lower travel times. This considering using NTR's or some other form of propulsion that allows higher delta-V transfers. If I set the bounds to give me a transfer of, for example, 120 days or less to Duna(Mars) it still gives me a standard fly-by.

Edited September 23, 2014 by ANWRocketMan

[Arrowstar]

Still a teeny bit of misconception between us I think I'm pretty sure I know where it is though. When I said the user would return to MA and prompt it to fetch the new orbit, I didn't mean to imply that during the time the game is running MA is continually streaming anything via KSPTOTConnect. Here's a flowchart I hacked together real quick:

http://i.imgur.com/3pi4ZFN.png

So the idea is you have the original orbital state (A) - which is what MA calculated to get your craft Pe just outside the atmosphere, and then you are providing MA a second orbital state (, which is the new orbit of the craft after exiting the atmosphere in the game. The only real legwork MA has to do is to calculate the dV needed to get your craft from state A to state B. I don't mean for that to sound simple, because it probably isn't. But that's all I was meaning for MA to do - possibly with an internal run of the optimizer that uses the new orbital parameters as constraints. Again this would appear to MA as a burn at Pe that doesn't use any fuel mass.

Got it! Thanks for taking the time to put together a detailed description. Unfortunately I still don't think it's feasible to pull off, mainly because of the time required to go from starting the KSP orbit propagation to ending it. The mission optimizer and related functionality has to perform a large number of function calls per second to finish in a reasonable time, and the added time to communicate with KSP and wait for a result to come back would be prohibitive. The other issues are surmountable I think, but that one isn't as far as I can tell.

That said, I'm definitely game to try out a new aerobraking maneuver type (using the approximation I described earlier) for v1.1.8. I'd be happy have you test it out for me if you're up to it.

I just created a Duna mission to 30km Pe and set the COAST event to 10 minutes prior to Pe. However when I tried to load a craft onto this orbit using the Final State data and Hyperedit, it told me the craft was out of Duna's SOI. I tried manually editing the save file (looked up the parameters in the KSP wiki to make sure proper info was being assigned) and the game just deleted the craft. I wanted to run the craft through the atmosphere, and then import the new orbit into a new SET_STATE and see how MA reacted. I think I just didn't set the parameters right for a hyperbolic orbit.

So instead I Hyperedited a craft high around Kerbin and burned to lower my Pe within the atmosphere. I loaded this orbit into MA, coasted a few mins prior to Pe, then created a new state once the craft had left the atmosphere with the new orbit. MA reacted by saying my ship landed and took off again. In the aerobrake scenario I described, it would properly connect the orbits.

Both mission files are uploaded here.

Thanks, I'll take a look!

Also, found this "Documentation of KSP Physics" in the tutorials section and wondered if it would be of any help for anything. It does mention Lat/Lon conversions

Ah! So that document actually doesn't compute the longitude correctly because it assumes that inertial X is aligned with body X at t = 0. That's not the case for most KSP planets and moons. If that's what SCANSat and the others are using, then it would appear there is a flaw in their code.

So I'm trying to plan a tricky maneuver using Mission Architect, and I'm not figuring things out quite right. I'd appreciate any help.

I have a craft in Kerbin orbit (and can get state from the SFS, no problem). I departing Kerbin and transferring to Jool with a low Pe over Jool (~8000km radius). Somewhere near the Jool Pe (maybe before, maybe after), I'll make another burn to adjust my swing around Jool and intercept Pol. Unfortunately, while I can work up a mission that gets me an 8000km periapsis and very little inclination, I can't seem to find the Pol intercept. The optimizer ends up halting with a Pol-periapsis of 50Mm, or 100Mm.

Using a fake orbit (prior to launching the actual spacecraft), I was able to find a mission that got my into an equatorial Pol orbit for about 3300m/s (1950m/s to transfer to Jool, 350m/s to intercept Pol, and 1000m/s to capture in Pol orbit). But reloading with the actual orbit shifts things enough that I can't locate any solution anymore.

A couple of runs with the Graphical Analyzer have suggested that Pol is basically on the wrong side of Jool when I make the fly-by. If I know where Pol is when I swing by Jool, I can advance or delay my Kerbin departure to compensate and place Pol in the right section of its orbit. But I can't quite determine where Pol IS when I fly-by.

Is there some way of determining where Pol is in relation to my spacecraft at the fly-by? Some other way of laying up the mission that can allow the optimizer to find a feasible solution?

-Brian

Okay, so try setting up your inbound orbit into Jool such that it has a RAAN of +180 degrees of what it is now. That may help. If not, try playing around with the inbound RAAN more. You should eventually be able to get Pol on the "right side" as it were. If you have a MAT file you want to upload, I'd be happy to take a look as well.

@Arrowstar: One last question. How can I determine the burn parameters for a fly-by mission where I'm using a much shorter transfer time from the porkchop plotter for fly-by's? The Multi fly-by maneuver sequencer does not seem to acknowledge my bounds on lower travel times. This considering using NTR's or some other form of propulsion that allows higher delta-V transfers. If I set the bounds to give me a transfer of, for example, 120 days or less to Duna(Mars) it still gives me a standard fly-by.

The Multi-Flyby Maneuver Sequencer finds the delta-voptimal transfer orbit, not the time optimal (shortest) transfer orbit. If you want the MFMS to find a shorter maneuver, try lowering the maximum duration of the leg you want to shorten. Let me know if that helps. If not, take some screenshots and post it here so I can more specifically see what you're doing.

[Arrowstar]

SI just created a Duna mission to 30km Pe and set the COAST event to 10 minutes prior to Pe. However when I tried to load a craft onto this orbit using the Final State data and Hyperedit, it told me the craft was out of Duna's SOI. I tried manually editing the save file (looked up the parameters in the KSP wiki to make sure proper info was being assigned) and the game just deleted the craft. I wanted to run the craft through the atmosphere, and then import the new orbit into a new SET_STATE and see how MA reacted. I think I just didn't set the parameters right for a hyperbolic orbit.

So instead I Hyperedited a craft high around Kerbin and burned to lower my Pe within the atmosphere. I loaded this orbit into MA, coasted a few mins prior to Pe, then created a new state once the craft had left the atmosphere with the new orbit. MA reacted by saying my ship landed and took off again. In the aerobrake scenario I described, it would properly connect the orbits.

Both mission files are uploaded here.

Okay, so I took a the files you sent. In the Kerbin case, which I think was the one you're most interested in, it's not so much that MA thought you landed and took off as it is that MA just connected the final point of the first coast with the point representing the state you set afterwards. That it happened to go through the planet is a coincidence. Anyway, it looks like both you and MA did what you were supposed to do, and the visual peculiarity that you saw is just that.

Let me know if that helps!

[Drew Kerman]

Got it! Thanks for taking the time to put together a detailed description. Unfortunately I still don't think it's feasible to pull off, mainly because of the time required to go from starting the KSP orbit propagation to ending it. The mission optimizer and related functionality has to perform a large number of function calls per second to finish in a reasonable time, and the added time to communicate with KSP and wait for a result to come back would be prohibitive. The other issues are surmountable I think, but that one isn't as far as I can tell.

Hrm, we're still not quite on the same page. It still sounds like you're trying to talk to KSP while the aircraft is performing the aerobrake to determine the effect that it is having on its orbit? Again, there's no data streaming of any kind happening between MA and KSP. MA (via KSPTOTConnect) tells KSP "place craft on this orbit" (which could be the one in my Duna example). MA then queries KSP, after the user tells it the aerobrake pass is over, and asks (via KSPTOTConnect) "what's the new orbit?" - just as if the user were importing an orbit from KSP. In fact that's exactly what I was trying to show with this:

Okay, so I took a the files you sent. In the Kerbin case, which I think was the one you're most interested in, it's not so much that MA thought you landed and took off as it is that MA just connected the final point of the first coast with the point representing the state you set afterwards. That it happened to go through the planet is a coincidence. Anyway, it looks like both you and MA did what you were supposed to do, and the visual peculiarity that you saw is just that.

Now that you've confirmed it's just a straight connection between the orbits, what I actually ended up proving with this example (to myself, obviously no doubt you knew this) is that MA is okay with you ending an orbit there, and then picking it up again over here. I honestly did not consider when originally coming up with this idea the option of being able to create a new orbital state yourself! So forget everything I said about the AB_MANEUVER state and having MA calculate a new orbit, fuel-less burns... toss it all out! All MA needs to do is be able to export an orbit. The final state in the Duna mission example? If MA can tell KSP to place a user-selected craft onto that time/trajectory (which I failed to do manually), I can just do what I did in the Kerbin example - let the craft pass through the atmosphere and then create and import a new orbital state.

The fact that a line will go through the planet is rather cosmetic, as would be the LOW PE warnings, because I know what I'm doing (famous last words...)

Regardless - I promise I will be happy with either solution you choose to pursue!

Ah! So that document actually doesn't compute the longitude correctly because it assumes that inertial X is aligned with body X at t = 0. That's not the case for most KSP planets and moons. If that's what SCANSat and the others are using, then it would appear there is a flaw in their code.

I will pass this along to them, then

[Arrowstar]

Hrm, we're still not quite on the same page. It still sounds like you're trying to talk to KSP while the aircraft is performing the aerobrake to determine the effect that it is having on its orbit? Again, there's no data streaming of any kind happening between MA and KSP. MA (via KSPTOTConnect) tells KSP "place craft on this orbit" (which could be the one in my Duna example). MA then queries KSP, after the user tells it the aerobrake pass is over, and asks (via KSPTOTConnect) "what's the new orbit?" - just as if the user were importing an orbit from KSP. In fact that's exactly what I was trying to show with this:

Thanks for the clarification! I understand that there isn't any streaming going on between MA and KSP. In the scheme you're describing, there are only two points in time at which data is passed along, correct? This would be the point at which MA "exports" an orbit to KSPTOT via KSPTOTConnect, and the point at which KSPTOTConnect transmits the new orbit back to MA post-aerobrake. Does that sound correct?

If so, it would still be infeasible I think. Consider all the time you'd have to wait for KSP to finish propagating from the exported orbit to the end of the aerobrake maneuver. Now image doing that ~10000 times during the course of a normal script optimization run. It would quickly become prohibitive. I can see doing something like this if it was just to propagate an orbit through the atmosphere one time, but unfortunately I have to use the same method to propagate during optimization as I do during the normal "single shot" propagation.

Thanks for going back and forth with me on this. I admit I may not still have my head fully around your idea, so if it sounds like I'm missing something still, please point it out. And, if so, please do address my concern about mission optimization.

Regardless - I promise I will be happy with either solution you choose to pursue!

Thanks! Unless I'm wildly off the mark with what I wrote above, I think I'll be pursuing the approximation method. Either way, it sounds like v1.1.8 is going to be the aerobraking update!

I will pass this along to them, then

Thanks. Please do let me know if they have any questions (or flat out think I'm wrong ).

---

In other good news, I added the ability to record Mission Animator animations to .avi files this evening. I must say, it works lovely. And as this was last "feature" I wanted to get into Mission Animator, pending feedback after the v1.1.7 release, Mission Animator is feature complete! Woot!

[Drew Kerman]

Thanks for the clarification! I understand that there isn't any streaming going on between MA and KSP. In the scheme you're describing, there are only two points in time at which data is passed along, correct? This would be the point at which MA "exports" an orbit to KSPTOT via KSPTOTConnect, and the point at which KSPTOTConnect transmits the new orbit back to MA post-aerobrake. Does that sound correct?

Okay, we're on the same page here...

If so, it would still be infeasible I think. Consider all the time you'd have to wait for KSP to finish propagating from the exported orbit to the end of the aerobrake maneuver. Now image doing that ~10000 times during the course of a normal script optimization run. It would quickly become prohibitive. I can see doing something like this if it was just to propagate an orbit through the atmosphere one time, but unfortunately I have to use the same method to propagate during optimization as I do during the normal "single shot" propagation.

And okay, now I think I see where you're coming from - but don't really understand how the optimizer becomes involved in this. There's nothing to optimize right? Take the Duna mission script I linked you to for example. Let's say I export the orbit, run through the atmosphere, and then re-import the orbit as a new SET_STATE (like the Kerbin example). Now, moving forward with that new orbit I could, say, try to set up an encounter with Ike via the RMS. Then use the optimizer to get a good Ike encounter. Or, I could re-optimize prior to the SET_STATE event to maybe lift my Pe a little higher in the atmosphere, then re-export, run the game and update the SET_STATE event with a new orbit and try to optimize an Ike encounter from there. You can already disable events from being allowed to be optimized, and SET_STATE events have no optimization options anyways so I'm a bit confused as to how the optimizer plays any role here, or why it even would.

Again, the Kerbin mission file is a literal example of what I'm proposing the script would look like post-aerobrake (now that I've realized the only new thing MA has to do is export an orbit). Take events 3 & 4 from the Kerbin script and tack them on the end of the Duna script - that's what I was going for until I failed to get the orbit manually set in the game. If the "break" in the Kerbin script between events 2 & 3 isn't A Good Thing that should normally be done, then I didn't realize.

Although, I realize now maybe what you're really saying is "I'd like to allow this way to be optimized, but this way can't feasibly be optimized, however the approximation way can". Well, if that's the case then yea might as well go for the approximation because you're right - spending the time (even under time/phys warp) for an in-game aerobrake to come out on a useless orbit and having to guess at a better dip through the soup would be a pain compared to letting the optimizer guesstimate it for you.

In other good news, I added the ability to record Mission Animator animations to .avi files this evening. I must say, it works lovely. And as this was last "feature" I wanted to get into Mission Animator, pending feedback after the v1.1.7 release, Mission Animator is feature complete! Woot!

And here I was slightly dreading having to dig up a cheap desktop capture tool to get the job done. I can't find the Donate button. Why is there not a Donate button??

Edited September 24, 2014 by Gaiiden

[Arrowstar]

Although, I realize now maybe what you're really saying is "I'd like to allow this way to be optimized, but this way can't feasibly be optimized, however the approximation way can". Well, if that's the case then yea might as well go for the approximation because you're right - spending the time (even under time/phys warp) for an in-game aerobrake to come out on a useless orbit and having to guess at a better dip through the soup would be a pain compared to letting the optimizer guesstimate it for you.

This is basically it. More generally, it has to do with the fact that any time you change any event prior to the aerobrake maneuver, you would have to recompute the aerobrake. Want to slide add a deep space maneuver to lower delta-v somewhere? Recompute. Want to adjust your initial orbit based on what your launch vehicle actually accomplished? Recompute. And so on. I foresee something like that just getting tedious and hard to use effectively.

Here's what I'm going to do. I'll work on the approximation for v1.1.8. You can test it out and we can decide if it's worth having around (that is, does it do a decent job of predicting the effects of atmospheric drag or not). If it doesn't, we'll revisit all of this. I am fairly confident that it will work, though.

Btw, I really do appreciate your taking the time to lay out this idea for me. It's definitely nice to know that there are folks who are invested enough in my software that they're willing to go to bat for changes they want to see.

And here I was slightly dreading having to dig up a cheap desktop capture tool to get the job done. I can't find the Donate button. Why is there not a Donate button??

I don't really like the idea of accepting money for KSP TOT, hence no Donate button. Give to a local charity what you would give to me if you'd like to give anything at all. And you can donate your time with the KSP TOT wiki, whenever I get around to creating that (hopefully soon, just need a Github repo with my code on it...).

[Drew Kerman]

Here's what I'm going to do. I'll work on the approximation for v1.1.8. You can test it out and we can decide if it's worth having around (that is, does it do a decent job of predicting the effects of atmospheric drag or not). If it doesn't, we'll revisit all of this. I am fairly confident that it will work, though.

Yea, I totally understand now how effective my method would be for a single use case but overall... yea, could get tedious. If that were the best that could be done though, I would call it worthwhile. Having the other method however certainly does provide an advantage even at the loss of accuracy. Peh. Accuracy. That's not fun That's not kerbal!

Btw, I really do appreciate your taking the time to lay out this idea for me. It's definitely nice to know that there are folks who are invested enough in my software that they're willing to go to bat for changes they want to see.

I'm just glad my persistence didn't come off as hostile or demanding, as I've seen happen in some cases from both sides (author, user). Was worried this whole time honestly of just pissing you off in the end

I don't really like the idea of accepting money for KSP TOT, hence no Donate button. Give to a local charity what you would give to me if you'd like to give anything at all. And you can donate your time with the KSP TOT wiki, whenever I get around to creating that (hopefully soon, just need a Github repo with my code on it...).

Fair 'nuff. Just want you to know you deserve it IMO

[Arrowstar]

Yea, I totally understand now how effective my method would be for a single use case but overall... yea, could get tedious. If that were the best that could be done though, I would call it worthwhile. Having the other method however certainly does provide an advantage even at the loss of accuracy. Peh. Accuracy. That's not fun That's not kerbal!

I'm actually hoping it'll be fairly accurate once you get the correct ballistic coefficient into the equation. We'll see!

I'm just glad my persistence didn't come off as hostile or demanding, as I've seen happen in some cases from both sides (author, user). Was worried this whole time honestly of just pissing you off in the end

Not at all. As I said, I'm just happy that people use KSP TOT enough to care about feature requests. It's kind of a small user community we have here.

Fair 'nuff. Just want you to know you deserve it IMO

Thanks, I definitely appreciate the sentiment! Everyone likes to be appreciated after all.

[Arrowstar]

Hi everyone, some good news here. While I wait for RadarManFromTheMoon to get back to me about finishing up some great improvements on KSPTOTConnect (should be done tomorrow I hope?), I've been looking at the speed at which Mission Architect runs when there are many events in the event script, say for example fifteen events.

The big slow down with cases such as these is the need to search for SoI transitions. If you leave Kerbin's SoI, there's a chance you could hit Duna, or Jool, or Eve, or where ever. Even if you stay within Kerbin's SoI, you might still hit the Mun or Minmus. In each of these cases (and many others!), the spacecraft's existing orbit needs to be checked for SoI transitions, and if such a transition exists, it needs to be handled.

Now, a few updates ago I implemented a system by which the SoI transition checker would only check for SoI transitions where the spacecraft was between the periapsis and apoapsis of the celestial body being checked. This was a great improvement and led to some sweet accuracy and speed improvements. However, there's another factor here that wasn't accounted for at that time: the celestial body in question may be no where near the spacecraft within that interval! In the current version of Mission Architect, SoI transition searches are run regardless of this factor, resulting in many wasted calls to an optimizer.

In the upcoming version of KSP TOT and Mission Architect, I've resolved this. What I'm doing is comparing the distance between the spacecraft and the celestial body at the end points of the (small) interval where the spacecraft is between the periapsis an apoapsis. If the minimum of those distances is greater than some fraction of the celestial body's semi-major axis, the SoI check is aborted without going to the optimizer.

In my tests, this results in a speed up of roughly x2. It's not the order of magnitude increase I was hoping for, but it's still pretty cool! Neat, huh?

[Drew Kerman]

efficiency FTW! Possible slight increase, since you only say "celestial body": if the SOI check is being done along a heliocentric orbit, does it automatically exclude all moons?

[Arrowstar]

efficiency FTW! Possible slight increase, since you only say "celestial body": if the SOI check is being done along a heliocentric orbit, does it automatically exclude all moons?

You are correct. It only checks for the immediate children of the central body the spacecraft is orbiting around (or, we could also say, the immediate peers of the spacecraft).

[diomedea]

...

In the upcoming version of KSP TOT and Mission Architect, I've resolved this. What I'm doing is comparing the distance between the spacecraft and the celestial body at the end points of the (small) interval where the spacecraft is between the periapsis an apoapsis. If the minimum of those distances is greater than some fraction of the celestial body's semi-major axis, the SoI check is aborted without going to the optimizer.

That is certainly interesting. If I had devised something to limit the checks for SoI changes, I would have considered a sequence of checks. Distance from the SoI mainbody seems to be fast to check, and good in most cases to discriminate; but if the distances match I would then consider the phase angle of the two objects to further limit the search; and if possible without much detriment to the algorithm speed, I may have considered a third check about the vertical separation of the objects (with some weird math about inclination and true anomaly by distance to find the vertical displacement to the ecliptic plane).

I believe the SoI change is actually dictated by the distance of the craft from the new body, unless there is some tricky change in reference system that involves a lot of math, computing the distance may be easier than the vertical separation, so that third check may not be worth the time taken.

Also, how often is called the routine that checks for possible SoI changes? Or, how small the interval moved along the trajectories before another check is done? I would consider to do another check only after the craft has moved a distance equal to how distant it was from the closest body, minus the SoI range of that body.

[Arrowstar]

That is certainly interesting. If I had devised something to limit the checks for SoI changes, I would have considered a sequence of checks. Distance from the SoI mainbody seems to be fast to check, and good in most cases to discriminate; but if the distances match I would then consider the phase angle of the two objects to further limit the search; and if possible without much detriment to the algorithm speed, I may have considered a third check about the vertical separation of the objects (with some weird math about inclination and true anomaly by distance to find the vertical displacement to the ecliptic plane).

I believe the SoI change is actually dictated by the distance of the craft from the new body, unless there is some tricky change in reference system that involves a lot of math, computing the distance may be easier than the vertical separation, so that third check may not be worth the time taken.

Also, how often is called the routine that checks for possible SoI changes? Or, how small the interval moved along the trajectories before another check is done? I would consider to do another check only after the craft has moved a distance equal to how distant it was from the closest body, minus the SoI range of that body.

Ah, so, the SoI check it only performed once per coast evaluation, nominally. Of course, if you do transition SoIs on a coast, then after said transition occurs, another check is performed on the new body you're orbiting around. The SoI check is a few operations in sequence:

1) Sanity checks: is my periapsis sufficiently above the periapsis of the target body and my apoapsis sufficiently below the apoapsis of the target body that I would never intersect their SoI? (if yes, skip SoI check)

2) orbital plan check: some calculations are done with respect to the angular separation of the angular momentum vectors: small separation means the bodies are nearly co-planar and more likely to intersect, but large separation means that there are only two probable locations that an SoI transition would occur (the nodes of the orbit). It's hard to explain without showing the math, but basically, the more co-planar the orbits are, the more likely it is that the SoI check continues;

3) My new "distance between bodies at arc endpoints" check, above; and finally

4) The actual SoI check: minimize the distance between the spacecraft and the celestial body's SoI boundary. If that distance goes to 0, you've transitioned. If it remains above 0, there is no transition. There is where I use the optimizer and where things get CPU expensive. All the rest of those steps occur very, very quickly.

And that's basically the gist of it.

[mhoram]

Ah! So that document actually doesn't compute the longitude correctly because it assumes that inertial X is aligned with body X at t = 0. That's not the case for most KSP planets and moons. If that's what SCANSat and the others are using, then it would appear there is a flaw in their code.

Please leave me a note, if you happen to stumple upon other inconsistencies in the document. I would like to get it free from such issues.

Added a remark in the PDF about this problem.

[Arrowstar]

Please leave me a note, if you happen to stumple upon other inconsistencies in the document. I would like to get it free from such issues.

Added a remark in the PDF about this problem.

Thanks for the note, I will!

[diomedea]

Ah, so, the SoI check it only performed once per coast evaluation, nominally. Of course, if you do transition SoIs on a coast, then after said transition occurs, another check is performed on the new body you're orbiting around.

....

And that's basically the gist of it.

Definitely, very interesting. Yes, the orbital plan check is clear. And that sequence makes clear why most of computing time is spent on the actual SoI check, the optimizer has to make a few runs to solve for the transition.

Though, I was thinking previous steps had more importance (so much to allow that important gain in time you wrote before), and guessed it was required to have multiple checks if a coast segment was crossing the orbits of a number of different bodies .

[Arrowstar]

Hi everyone,

This evening I am pleased to announce the release of KSP Trajectory Optimization Tool v1.1.7! This is a nice update with the following features:

• Major improvements to the KSPTOTConnect netcode courtesy of RadarManFromTheMoon. These improvements significantly increase the robustness and speed of KSP TOT Connect, making it much more enjoyable to use. Thanks, RadarManFromTheMoon!
  
• New Mission Architect Tool: Mission Animator. Mission Animator is a multi-purpose visualizer and animation creation tool for Mission Architect.
  
• Three new objective functions in Mission Architect: maximize inclination, maximize eccentricity, and "satisfy constraints".
  
• 2x speed up of Mission Architect script execution when using Strict SoI Search
  
• Time may now be specified in Earth units or Kerbin units. NOTE: Kerbin units are HIGHLY experimental. Report any issues with KSP TOT while using Kerbin units immediately.
  
• Bug fixed with MA Graphical Analysis tool when plotting against MET.
  
• New "Distance Traveled" option in MA Graphical Analysis.
  
• Fixed two bugs with Maneuver Exec Assistant
  

The download is available in the OP, as always. Please note that this release is for Windows only at this time. I rely on bk2w to supply the Mac releases, and he provides me a Mac package at his convenience.

Please report any issues with the following new features:

• KSPTOTConnect;
  
• Mission Animator; and
  
• Kerbin time units.
  

Have at it, everyone, thanks! I'm looking forward to seeing some sweet animations in the future.

---

Oh, quick announcement about what's on the plate for v1.1.8. This update will be the Aerobraking Update and should hopefully include an aerobraking delta-v model that I will begin to incorporate into Mission Architect next week. Stay tuned! Edited September 26, 2014 by Arrowstar

[RadarManFromTheMoon]

playing atround with it a bit. Told the Mission Architect to coast to a given UT, burn for the mun and then coast to the pe of the mun to finally circularize there. This is what I got:

he seems to get the soi change. But does not render it correctly

mat-file

[Arrowstar]

Thanks for the report!

Something weird is going on with your burn but I haven't figured out what yet. I'll look into it...

EDIT: In the mean time, check out Mission Animator; you'll see that the spacecraft goes around once before the SoI change, meaning that the picture is rendered correctly. It's just unusual to go a full rev before actually getting to the Mun...

EDIT^2: Yup, okay, a bit of investigation later and it appears that there's nothing formally wrong. Mission Architect is doing what I told it to do, which is to search out more than one period for an SoI transition. (The number of periods it goes out is computed and, in this case, actually looks like it's 2.0.) You just got very lucky (unlucky?) to have the optimizer find the SoI transition on the second orbit around Kerbin instead of the first.

This "search more than one revolution" feature is more for safety than anything else. I can't always predict how many revs the user expects the SoI search code to go out, and so I set it to a compromise between not having enough (such as always just going 1 rev) and too many (going, say, 5-10 revs). Given that this is the first time I've seen this happen, I'm not sure what to say except "congrats!"

I'll solicit input in the thread here as to what people think Mission Architect should do in this case. If you have a thought, please post here. Thanks!

Edited September 26, 2014 by Arrowstar

[RadarManFromTheMoon]

I' see. Havent realized that. So the optimizer just prefers to burn as soon as possible even when poor Jebediah has to do an extra turn around an highly eccentric orbit? Thats not really a bug. How can one prevent that? Would it be possible, and sensible, to add an option like "minimize mission duration" to the optimizer?

[Arrowstar]

Would it be possible, and sensible, to add an option like "minimize mission duration" to the optimizer?

That's a good idea. I can certainly look into it!

EDIT: As for preventing it, I would encourage you to use the "go to true anomaly" coast and optimize on that as opposed to optimizing the UT of the burn. See if that does anything for you.

[bk2w]

I'm making progress with Mission Architect in my attempt to swing by Jool and intercept Pol. I'm having a lot better luck getting a solution by using the Jool-flyby to lower the apoapsis to somewhere around 400Mm, then burning at api to raise periapsis to near Pol's orbit. The Optimizer can then take over and tune those two burns to get close to Pol. Mission file is here; I'm still playing with it as it doesn't reach Pol quite yet.

I do have some suggestions to make the process a bit easier:

- When looking at the whole Joolean system with child bodies visible, the child bodies are so small that they visually merge with the arc of their orbits. I end up having to show SoI radius and popping the orbit display out so I can make it larger, before I can finally locate Pol and Bop. So it would be useful to make child bodies a minimum size and a contrasting color in order to make them visible.

- With multiple burns in the Joolean system, I see the locations of child bodies at multiple points on their orbits. I'm presuming these are the body locations at each event. However, it's difficult to tell which location correlates to which event. Could we color the bodies according to the event location corresponds to?

The Mission Animator is particularly interesting, and has the potential to be a really useful visualization tool.

- Can you add the option to display orbit arcs for child bodies? This would make identifying which body is which easier.

- When using "Custom" camera position, can you add a "zoom" capability? It seems that the Custom camera creates a 3D box the size of the entire SoI.

In other news, OSX version compiled and handed off to Arrowstar. If anyone else is successfully using the OSX version, please chime in; I'd like to know if anyone else is able to use it.

-Brian