Arrowstar

Other way around.

OK. Can I get a screenshot of your inputs so I can duplicate it? I would like to fix this.

Thanks for the bug report, Spanier. Did it output an error message? Can you paste it in, if you did? Can you also take a screenshot of your inputs so I can duplicate it?

I'm going to go ahead and shamelessly plug a tool I'm writing that might help you here. It's called the KSP Trajectory Optimization Tool and its add-on thread is located here. As far as I know, it's the only application available for KSP that will help compute optimal fly-by maneuvers. Give it a look and tell me what you think.

Okay. I'll demonstrate with MechJeb, but the principle will be the same regardless of the editor used. I'll get this out this weekend when I have more time.

Thanks, glad everything worked out! I've been using the "Departure Time" as the burn time in LKO, though since the patched-conics thing is only an approximation, you could argue either way. Something you might try: get the departure date and time from the Flyby program, then go plunk in the departure and arrival times from Kerbin->Eve into the Compute Departure program (accessible from that button on the main GUI). It should give you the same departure burn result. You can use that to iterate on the departure without having to rerun the who flyby optimization thing multiple times to iterate (which, now that I think about it, is impossible at the moment anyway). I feel like I should put together a tutorial on this whole iteration thing. Should I do that?

Hi everyone, I have the pleasure to announce the v0.7 release of the KSP Trajectory Optimization Tool! This is a major update that brings the following capabilities: A Flyby Maneuver Sequencer(FMS)that is capable of searching for optimal flybys (gravity assist maneuvers) around planets. Spending too much fuel on that trip to Moho? Try a flyby around Eve first! Optimal launch/arrival date is now the default setting in the Compute Departure GUI. "Time To Periapse" is now shown alongside "Time After Periapse" in the DV Maneuver Information boxes in the Departure Information GUI and the FMS GUI. Useful for using maneuver node editors mostly. Some minor visual changes/tweaks to the plots. Some bug fixes and a code reoganization on the back-end. The ZIP file in the original post should be updated by now. Go check it out! (Note: for those who tried the 0.7 prerelease 2, this is the same executable. I didn't have any changes to make after yesterday, so I'm calling that good for now.) Yep. That's because this problem is pretty hard. To hit targets on a finite duration burn or optimize the same could require something called variational calculus. I've taken some coursework in the field and while it's very interesting academically, it's not worth implementing here. And really, I promise, the impulsive burn model will serve you just fine 99% of the time in KSP. So, the problem is probably just that the solver didn't find a good solution. This can happen sometimes. The PSO solver is not fool-proof and it occasionally doesn't produce good results. The only way to mitigate this is to add more particles, which is more expensive to evaluate. I've picked settings that I think represent a good balance between speed and accuracy. tl;dr: If you get terrible results, try optimizing again (maybe with a larger launch window). I'm glad it worked for you! Very good job. Next time, could you take some screenshots of the game's map and KSP TOT's output so I can compare? A couple points on your comments. First, the actual initial orbit you provide isn't used up until the code says "Computing Departure Orbit." I assume that if I can minimize the hyperbolic excess speed of departure, I've minimized the actual departure delta-v, so I don't need to use that information right away. This makes it faster to optimize the whole problem. The assumption isn't strictly true, but it's a good enough approximation. Second, regarding the time of launch: Your actual execution time of the burn is critical for these maneuvers. If you run the tool once, get a departure time and a departure true anomaly and then create a maneuver node, what you'll see is that the departure time doesn't match what KSP TOT is telling you that you need. You'll probably be off on the order of minutes. This about the speed of the planets though: multiple km/s. So how many kilometers would, say, Eve move in the space of 30 minutes? Enough to throw off your arrival trajectory, easily. How do you get around this? You do what we astrodynamicists do a lot of in the Real World: you iterate on your solution. Compute a departure time, toss the burn information into KSP, and get your actual departure time. Put this actual time back into KSPTOT, reoptimize the departure, then put the burn information back into KSP TOT. In one of two iterations, you'll see that your KSP departure time and your KSPTOT departure time are basically the same. That's the burn information you'll want to use to get to Eve. I agree with your points in (2), but there's not much I can do about them sadly. I'll see if I can mitigate the problem any, though... Thanks for the great feedback! Here's a little preview of what I worked on today. It's a continuation of something I showed yesterday, but with a partially working GUI... Anyone want to guess?

Alright guys, I've fixed up a bunch of the bugs and suggestions you all have had provided. Thanks! I've compiled all this into the v0.7 prerelease 2. Since this version has so many large changes, if I could ask you guys to take another look and see if anything has been left out or any bugs have surfaced, that'd be great. Here's the updated ZIP file. Same deal, just the EXE and no source or license. All of that will come with the formal 0.7 release. If all goes well, that will be tomorrow. Please let me know what you think. Thanks for all your help, guys! You rock.

Thanks for the bug notes and test information! Bug 1 is unfixable, as the data cursor does not conform to the ui stacking order of the rest of the GUI (if someone can prove me wrong here, please do!). Bug 2 is intentional for now. Getting things to resize nicely is a bit harder than it sounds and I'll tackle it at the end, once I get everything functional. Bug 3 is a good one. I'll add a note to handle this for 0.7. Fixed. Also, the status window text is now selectable as well... I'll look into how the solver behaves with departure and arrival bodies that are the same. As far as TOT for Orbiter goes, please shoot me a PM with questions and we can talk more there. I'd like to keep this thread on topic. I will say that the two applications were compiled with different versions of the MCR and thus two different MCR versions are required to run them... Noted, thanks for the trial run. Sadly, the tweak you're asking for is really more of a major overhaul of the code. The lambert solver I'm using assumes instantaneous delta-v. To correctly model "long" burns, I would have to write an orbit propagator to model the thrust correctly. That is a huge task and not one I'm looking to take on at the moment. In the mean time, here's how I would deal with the problem. 1) Compute a two burn solution. 2) Get as far along the first burn as you can. 3) Note the post-burn orbit and recompute a new optimal two-burn solution. 4) Execute new burn plan. 5) Repeat until you get the orbit you want. This method ensures that your execution errors are accounted for and corrected while allowing for multiple burns to take place. Sometimes it's all about working within the limits of the tool you have. Thanks, means a lot! Hey Wingnut, I have good news... Consider it included for 0.7.

I would love to participate as well!

Oh, just another little thing I'm working on today. This code is looking for the best way to take the given orbit around Kerbin (here) and turn it into the desired orbit. Magenta line is the orbit the spacecraft started in, blue line is the desired orbit, and the dashed black line is the transfer orbit between the two. The red line you see represents the burn direction (in this case, the second burn - the first burn is smaller and hard to see). In particular, in this example I started with the standard equatorial, circular orbit around Kerbin with an SMA of 800 km. I then asked the code to make the following changes to the orbit: Change eccentricity to 0.1 Change inclination to 30 degrees The black line represents the best transfer orbit between the two orbits and the red line/lines are the optimized burns. Eventually, I'll put together a GUI for this similar to the flyby maneuver sequencer GUI, and it'll be accessible within KSP TOT just like the FMS is. Some possible uses for the new tool (which has yet to be named): Finding the best way to get into that optimal Kethane scanning orbit around Minmus. Tweaking your inbound hyperbolic orbit towards Duna so that you can easily enter your desired science mission orbit. And more!

Thanks! And yes, however you'd like to use it is fine. Looking forward to seeing how you do!

Please do! If you could document the whole thing with screenshots, that'd be great. It would certainly be helpful as I determine what changes I can make to improve the user interface. Btw, do you use Mechjeb 2? I would recommend using it for the orbit panel and the maneuver node editor so you can create those maneuver nodes precisely.

Yes, that's not unexpected. There are a lot of local minima in the trade space and the PSO solver, while good, can't usually avoid them all, and when this happens it tends to fall into different minima. Thus we end up with slightly different results each run. It's unavoidable and usually not too big of a deal.

Mr Shifty: Thanks for the information! This is really useful. By "phase 1" do you mean the segment where the solver looks for feasible initial states? And by "phase 2", do you mean the actual solver run, with the PSO plot that comes up in a separate window? Togfox: I would love to see you give KSP TOT a go here. Universal time (UT) is available in two places. You can grab it from the Tracking Station, and if you use MechJeb 2, you can also put UT on a window using the window editor. MechJeb is really necessary for using this program in KSP, to be honest, because only by physically entering the delta-v quantities and getting your current orbit can you really make use of everything KSP TOT has to offer. I would love some feedback from you if you do decide to give the program a shot. EDIT: Also, I prefer to think that it wasn't a big bang that started the Kerbal-verse, but instead a Big Harvester:

Please note that the calculations for atmospheric drag loss are, in general, highly path (that is, trajectory) dependent. How much fuel you expend on your way to orbit depends on how you fly. Any mathematical relationship you see for atmospheric drag loss should be regarded as a loose approximation until you get in game and can verify manually.

So has anyone heard from KospY in a while? Is development of KAS still continuing?

Alright, folks, I need a beta tester for the v0.7 prerelease. This is unusual, but the parallel processing code I'm using (the stuff native to MATLAB) has a possibility of running differently on different system architectures. In particular, I'm looking for someone who can run the Maneuver Flyby Sequencer tool on a computer with a dual core processor. If you also happen to have a quad-core processor, run it on that too. Here's the ZIP with the application. No source or license stuff included here, I'm keeping this one simple. When you run the flyby maneuver sequencer (FMS), please use the following settings: Launch window open = 0 Launch window close = 157680000 Depart Body = Kerbin Flyby Body = Eve Arrival Body = Moho Initial Elliptical Orbit SMA = 800 All other initial orbit values = 0 I need to know two things: Did the application run for you? Could you enter the values above, push the Compute button, and get a solution to appear? Was your processor usage over (1/numCores)*100%? That is, if you have a quad-core machine, were you using total processor usage over 25%? This will be spread amongst multiple processes, so look at the total system usage, not just the KSPTOT.exe usage. The more people who want to give this a go and report results, please feel free. Report your findings and any problems here on this thread. (Btw, I already know the status box text on the main window says 0.6 and not 0.7 - this is fixed for next build. ) Thanks, guys!

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).