Arrowstar

No. Please realize what you're asking for here. The mission planners who designed the Voyager grand tour spent years looking for and refining that trajectory. KSP TOT is, by comparison, a very simplistic tool. Even if I thought I could find a solver capable of such a task, no one in the private world has enough CPU power to actually carry it out. This problem is far beyond the scope of this application... Answer to question 1: The porkchop plot is a N by N grid of calculated points. The point you see selected on the porkchop plot with the tooltip is the best point of those computed while generating the plot. The point provided in the tool window is the "best" point found by a fairly sophisticated optimization algorithm. The porkchop plot is designed to give you the "lay of the land", whereas the results of the optimization algorithm (in that status box) is actually what you can plan missions with. Answer to question 2: Because I haven't enabled that yet. I'll do that for the v0.7 release. Please let me know if that answers your question! If I can answer anything else, do let me know here...

Thanks! It's taken about a week to get things working nicely, but I think I'm on to something here. So, interestingly enough, it doesn't actually reduce the sample space. Here's why: To compute a fly-by, you first need to know where you're coming from and where you're going. So if your mission is from Kerbin to Eve to Moho, you need the Kerbin-Eve and Eve-Moho trajectories already figured out. This then defines the fly-by around Eve. Now, a standard gravity assist with no engine burn will have the same specific orbital energy at SOI entry and exit (w.r.t. the flyby planet, here Eve). However, your Sun-centered trajectory may require a higher exit energy than entry energy. In this case, you must expend fuel to make up the difference in energy. The solver is designed around a Lambert solver, which requires position vectors to the planets and a time of flight. Basically, you get these by selecting a departure date and two times of flight for your transfer arcs. The solver attempts to optimize the departure date and the flight times to the flyby body and destination body. These quantities dictate the Sun-centered orbits, which dictate the Eve flyby orbit, which dictates any delta-v you need to burn while flying by Eve. Now, I can constrain my solver such that the fly-by delta-v is 0, but then it really freaks out and has a hard time with the problem. Better to just let it come up with what it's going to come up with. tl;dr: Can't avoid engine burns in some cases because of orbital math. The problem is not the objective function being minimized (it's actually quite fast, since the Lambert solver is a compiled MEX file and that's the bulk of the work). It is, as you said, the size of design space and (more importantly) the number of function evaluations needed to do a good job traversing it. I'm using a particle swarm optimizer (it's on the MATLAB file exchange and I'll include the BSD license the first time around this time lol), which takes a population of particles and uses them to find global minima. Now, I also have a speedy Core i5 processor, and I can tell you that even 100 of those particles is a lot, even running the optimization in parallel mode on all four cores at once. If I increase the trade space to another flyby, I'll need even more particles, the whole thing takes longer, and my electric bill spikes because of the insane CPU usage. In short, I've explored it and it's not really feasible for my tool. Now for something completely different!Here's what I did today. I think it's fairly self-explanatory, but I'll point out a few things here. First, the trajectory was my favorite Kerbin-Eve-Moho. I started in LKO and entered the solid white line on the trajectory plot. I then swung by Eve and entered the dashed white trajectory. A bit later I arrive at Moho! You'll see that the GUI is set up very much like the Departure Information GUI for showing single transfer arc information. All required information about the Kerbin departure hyperbolic orbit and the Eve fly-by hyperbolic orbits is given. Same goes for the Sun-centered transfer orbit arcs. I also provide the usual information you need to execute the departure from Kerbin and the fly-by around Eve. Next up I will get the apse and node markers on the transfer orbit map. After that, I'll probably release (tomorrow or Monday maybe) and try to get some feedback. I should note here: Flyby optimization is computationally intensive. Be prepared to wait a few minutes for the software to do its thing. So, thoughts? I really think KSP TOT is shaping up to be the premier mission planning software for Kerbal Space Program.

Thanks for the fixes, Majiir!

Hi guys! I wanted to offer a sneak peak of where they fly-by optimizer is at right now. I've been looking at a number of trajectories to serve as examples, but the one I like the best is the Kerbin-Eve-Moho flight plan. As we know, flying to Moho is usually pretty expensive. The one KSP delta-v map I looked at (not terribly accurate, but it'll do here) suggests 2.2 km/s == 2200 m/s. This evening, I asked my solver to find me a cheaper trajectory to get to Moho by using Eve as a fly-by. Here's what it came up with. (Red trajectory is the to-Eve trajectory, blue is the to-Moho trajectory.) And here's what the trajectory around Eve looks like. The delta-v number of there is the amount of delta-v that the s/c needs to apply at periapse of the fly-by in order to hit the outgoing trajectory (and thus the target planet). In this case, the solver found a great ~0 m/s delta-v trajectory. The periapse around even was ~800 km in radius. Here's some other relevant information that the solver spits out. Departure DV = 0.852133165506862 km/s Arrival DV = 4.71245869089299 km/s Okay, now I realize that the arrival dv is a bit high. The solver is only looking to optimize the departure and fly-by delta-v right now. I found that throwing in the arrival delta-v resulted in a poor departure and a poor arrival. This way, at least leaving is very easy. When I get things put together this weekend, I'll include the option to add arrival delta-v to the optimizer, but no promises on how that will work out when you actually go to run it. I'm still working on GUI design at this point, but that should be straight-forward. Please note that, despite my best efforts and about a week's worth of work, this is still going to be a challenging tool for the average user to use. The PSO (particle swarm optimizer) I'm using doesn't get consistently good results (though I'll be the first to say it does really well most of the time!), and frankly, some trajectories are just going to be stupid. (Flyby around Dres? How about no.) This will require some knowledge of what you're ultimately going for unless you have days of CPU time for the solver to go through every possible trajectory (an impossibility) to find the good stuff. And as I said, some trajectories will either not be possible or cost much more than their equivalent direct Lambert arc siblings. Anyway, it's all in good fun. I may allow the use of two fly-by bodies if I think it's possible, but that'll be the limit. It already takes 5-10 minutes to try and optimize a 1 fly-by trajectory: any more than that and things are going to start getting expensive. Anyway, thoughts? Comments and questions are welcome as always.

Hi everyone, I'm happy to announce the release of v0.6 (main posting pending update shortly). This is a relatively minor release I'm using to get some basic outstanding features out of the way before I go ahead and implement my experimental "fly-by" solver code (the math of which currently functional - basically it needs a GUI.) New functionality includes: -Lone Wolfling's "minimize arrival time" with variable departure time optimizer; -The ability to input arithmetic statements (2+2 for example) into numeric text boxes and have them evaluate (so if you enter 2+2, the box changes to read 4) -"Optimize Departure for Input Arrival" now uses the input departure time as a lower bound. Useful for when you're in the middle of a game and you clearly can't go back in time to find that "better" solution. -Some bug fixes and tweaks under the hood. Most of my work the past week has concentrated on getting the fly-by math worked out and working prototype code implemented, which is why this release is pretty minor. Nevertheless, I think it's a improvements, while small, are helpful. As always, comments, questions, and questions are welcome. Please also let me know if you find a bug or something works not as expected. Thanks!

Hi everyone, Just a quick development update this morning. I plan on getting 0.6 out the door tonight if possible. This is a minor update that includes the following: -Lone Wolfling's "minimize arrival time" with variable departure time optimizer; -The ability to input arithmetic statements (2+2 for example) into numeric text boxes and have them evaluate (so if you enter 2+2, the box changes to read 4) -I am going to change the "optimizer departure time for given arrival" to use the current input arrival as a lower bound for the optimizer. This way you don't end up with solutions in the past if you don't want them. -Other minor bug fixes and enhancements My plan is for 0.7 to be the "flyby optimizer" release. I've been spending a lot of time lately on getting this to work (hence the slowdown in my posting and releasing new versions of this), and I think I've got it at the point where it's at least release-able. To be honest, my research into all of this suggests that fly-bys aren't as useful as one might think, but I'll provide the functionality and let people mess around with it anyway. Was there anything else quick you guys wanted for 0.6? If I can whip it up in a few hours tonight, I'll include it.

Got it. Those improvements sound really wonderful. Would you consider adding multiple converter resource recipes to a future 0.8? Of course, I don't know how tough this would be, but it's effectively the only thing stopping me from adding all sorts of new resources to go searching for (because I need a reason to look for them).

Can we expect a 0.7.3 or will this go into 0.8?

Okay, I understand what you want. I'll see about implementing this tomorrow. Sorry for the delay, I've been having too much fun with the Kethane 0.72 release. 1) I'll look into it. Not sure how hard it'll be to keep everything synced up, but will investigate. 2) Yes, I need sane defaults. I actually had it doing this originally, but I ran into a bug and the workaround was to eliminate the default setting. I've got an idea to fix it though, will try to get to it tomorrow or this weekend. I'm working on that right now. The math is all figured out and coded up, but the problem is still very tricky to solve. Not sure at this point if it will every make it into the main program. Keep checking this space for more updates.

Was there a live development stream yesterday? Or are you referring to the previous stream last week?

Ah indeed. Yes, one of the most important features of fmincon (for me) is the auto-differentiation. If I didn't have that, I'd either have to write my own, which I grant you would not be too terrible, or try to find analytic gradients for my problem, which I suspect don't exist. It makes my life a lot easier that MATLAB can do this for me, and in a (fairly) sophisticated way. Out of curiosity, what do you do that has you working with numerical problems such as the one you described?

Guys, I think serious thanks are in order here. It appears Majiir just pulled an all-nighter so we can mine digital green gas from digital planets and moons, and that's really a lot more effort than is (or should be!) required to maintain a mod. Majiir, you rock and Kethane rocks. Go take a cruise to the Bahamas or something.

That's the one. Thanks for pointing this out. I had this solver on my hard drive from another personal project a while ago and just grabbed the binary. I've added the license text file to the KSP TOT ZIP file. It's worth noting that I am using a "real solver." Indeed, the algorithms behind fmincon are quite sophisticated. What you mean is that you'd like to switch to a global solver... which is fine. I'm not using one of those here because I spent two years of graduate school working on this problem with MATLAB's genetic algorithm solver (simulated annealing is garbage for this.) It worked... okay, but it's very CPU intensive. As only as I only have 1 or 2 design variables to adjust (such as depart and arrival time) I'd rather just use the very quick fmincon and MultiStart, which works well for what I'm doing. That said, if you make progress, please do let me know about it. I'd be happy to see! Noted. I'll see what I can do. Okay, so it sounds like you actually want to minimize time of flight while allowing the code to shift the departure time to help minimize it further. I can do this. Unless, of course, I'm still not understanding, in which case maybe you could illustrate with an example. Yesterday I added notes in the relevant GUIs to help alleviate this. Thanks for the suggestions/tips tavert, Lone Wolfling. Very much appreciated!

Majiir, when KSP 0.21 is released (soon hopefully), will updating to that version (w.r.t. Kethane) simply be a matter of moving our save folder and Kethane folder from GameData into the new 0.21 installation? Btw, I've been using 0.71 today and with the exception of previously reported bugs, everything looks good!

Hey Majiir, did you mean to have the Resource Info tooltip appear in the flight scene (both while the scanner is off and on)? It feels a bit odd.

Woot! Thanks, Majiir! That's hilarious.

Nice! Can't wait to play with it, Majiir! You're the man! Woot woot! I don't suppose you'll tell us what the secret is? (Yeah, didn't think so, lol.)

Another update: In addition to some of the work I described above, I also added the line of nodes to the transfer orbit plot: By rotating the image, it's easy enough to see which node is ascending and which is descending. I don't want to put markers on the map because things are getting pretty cluttered, so I hope this line is sufficient for everyone's purposes. As usual, suggestions and comments welcome.

Thanks, I'm glad you're enjoying it! I believe so, yes. Let me investigate though. It may be a bit of a hack since that information (time elapsed) is not natively available in the function I use to generate those. But I will see what I can do. EDIT: Yup, not only is it possible but I've just implemented it. In the process I cleaned up some calls to the MATLAB multistart solver and put them in a common function for easy access later. I also standardized the progress bar windows across all computation functions (they all use the same function now, so they all look the same). It's a small improvement that really adds a bit of polish on things. So basically what you want is a "minimize time of flight" function that is constrained by delta-v and varies either arrival time or departure/arrival time? Fixed. I've basically told the code to look for errors when doing so and throw up a nice message box with the error message MATLAB gives if something goes wrong. Fixed. Thanks for noticing. I thought about this, but decided against it. I don't want to force people to remember to set the plot type before they go into that window. My thought was this: even if you're only interested in optimizing the departure dv, you may still be interested the arrival dv as well, because it influences your aerocapture or whatnot. Hence, I made a separate option so people could have flexibility. One day I will have an option where you can alter and add to the celestial bodies in the application. Part of this is their orbital parameters. When I get this done, you could always enter your spacecraft's parameters here and then use it like you would any other planet/moon in the game. Those are the boundary between the Type I (short way, transfer angle < 180 deg) and Type II (long way, transfer angle > 180 deg) cases. The physics works out that you typically get this high delta-v boundary between the two sets of cases. As an example, see this JPL-generated porkchop plot. I believe it's doing this already, actually. On the departure information window, those are 3D plots. MATLAB has a bug in it where zooming in on 3D plots physically makes the axis larger, which means it starts to cover up other elements of my GUI. Hence, zooming has been disabled on those plots until I can figure out a work-around (not likely, I've been trying for years). Not immediately possible but on the radar. I am going to do a type of "burn planner" tool within KSP TOT that will compute the burns and whatnot based on information you provide about your vehicle. Part of that could be a "multi-burn" setup where you put a cap on delta-v per burn or specify the number of burns to break things up into, yes. I'll make a note. Thanks for the great suggestions! Btw, all bug fixes I've specified above will show up in v0.6... ---------------------------------------------------- Now for something completely different! I thought I'd share a picture from my trip to Jool yesterday. I used KSP TOT to plan the journey (of course) and after plunking burn times and delta-v info into MechJeb's maneuver node editor, this is the transfer I got in the game. I don't know about you guys, but nailing the transfer on the first pass without having to modify any of the numbers KSP TOT gave me is pretty awesome, I think.

I'll just leave this here... *whistles*

You know, if you were to release it on Tuesday, not only would you be following a time honored Orbiter-Forum.com tradition of releasing major add-ons on a Tuesday, but then you could play this video when you do.

Can I read into this far more than I legally should and (thus) make hopeful comments about 0.7 being released on/before Tuesday, then?

Nice! Out of curiosity, why the design choice to not show all resources at once on the map?

Sounds great. The new scanner map sounds like a blast to use. I'm also looking forward to the ability to define multiple conversion recipes in our converters, perhaps that will make it into 0.8.

Any other features coming in 0.7, Majiir? Or is the scan map the big thing?