Gravitas Shortfall

Hey, just downloaded this and I can tell that I'm going to love it. Considered writing something similar awhile back, but my background on the maths side of things was more than a bit lacking. A couple quick questions on the multi-flyby tool. I'm assuming this tries to optimize for dV within the given time constraints. Is there a way to specify (or is it already assumed) that I wish to enter orbit at the destination, or will it just get me to the destination without considering dV needed for capture? Or is the intent to just use the multi-flyby output as initial input for the mission architect tool, and then enter constraints there? Also, it looks like you aren't allowed to have the same body set for consecutive waypoints. Is there are particular reason for this? Perhaps there's no good use for it in the Kerbal system, but I know in real life, NASA will sometimes set up trajectories that perform multiple gravity assists around the same body - Cassini, for instance, had two consecutive Venus flybys, as I recall. Again, great looking tool - can't wait to play around with it more once I can find some free time.

When I remember, I'll put some retrograde separatrons on my final launch stage to push it back into the atmosphere after I make orbit, but I'm not horribly bothered by the occasional piece of debris. My parking orbits are generally low enough that in real life it probably wouldn't take that long for them to decay, so every once and awhile I just go to the tracking station and terminate anything that might get in the way of future missions.

We'll have to match speed with the asteroid regardless, so whether you intercept in Kerbin's SOI or the sun's, you'll be spending the dV to reach interplanetary velocities, so where would you actually save by doing the intercept around Kerbin?

When a rocket launches, the upward force is being applied to the bottom of said rocket by the engines of the first stage, and that first stage has to be able to support everything above it whilst under a force of >1 g. Thus any rocket capable of making it off the ground should, at least in theory, also be able to be supported by launch clamps attached only beneath the first stage engines. The vehicle in the screenshot isn't too much smaller than my largest launcher, which I support on the launch pad by means of 3 launch clamps placed below a fuel tank placed below a decoupler placed below each of the 19 first stage mainsails.

Computers and and lots of clever math: http://www.esa.int/gsp/ACT/inf/projects/gtop/gtop.html I've looked briefly at using PaGMO to calculate trajectories in KSP, but ran into trouble getting things to compile and run on Windows. I'll probably give it another try at some point, but I wouldn't complain if someone with either a Linux machine or more experience with Visual Studio decided to beat me to it.

Hmm, Top Gear... "Some say that he lives on the surface of Jool, and that his blood can be used to fuel LV-Ns. All we know is, he's called the Jeb."

I feel your pain - currently working on a 288T launcher myself (had one already, but let's just say it's reliability left something to be desired). You can always add more fuel and more engines, so the tricky part is making sure it won't fall part. As SRV Ron suggested, build in stages. That is, attach the very last stage to the payload first, launch it, and make sure it holds together across through the duration of the stage. Once that's working, add the second to last stage and make sure that holds together, and so on. Install mechjeb or some equivalent to get info on dV and TWR for each stage, and if you have a general idea of what sort of rocket you want, that info can guide your design. For instance, if you're doing serial staging and have the same engine type (mainsails, say) for every stage, then the optimal design will divide dV evenly between all stages. If some of your engines are more efficient than others, you'll probably want to give slightly more dV to those stages. I don't know off the top of my head what the optimal strategy is for dividing dV in asparagus rockets, but I've no doubt the answer is on this forum somewhere. Ideal TWR is apparently around 2 on the launch pad - personally I tend to end up quite a bit lower than that because I'm concerned about part counts, and so would rather use a slightly larger fuel tank than deal with cluster engines, but it's something else to keep in mind. And use lots struts, but use them smartly - you don't want to get your part count too high, and a little bit of flex is going to hold together better than something that's completely rigid.

I tried and failed numerous times to get this into orbit.

If you're aren't opposed to mods, MechJeb will give you helpful stats in the vehicle assembly building, including the thrust/weight ratio for each stage. Very helpful for designing launchers.

edit: weird delayed dup post - disregard.

Hmm, is the 3353 from Eve assuming you're starting from Eve orbit? If this is just an Eve flyby, then the ship should actually already be on a trajectory to more or less intercept Kerbin's orbit without any burn near Eve. Any burn just needs to adjust that trajectory enough to account for the fact that you aren't actually in an Eve -> Kerbin launch window. Also, this method is assuming an optimal transfer from Kerbin to Eve, but another thing someone could try is forcing an early or late transfer using the date constraints, and then seeing if you make up that DV with a more favorable return.

Here you go: http://alexmoon.github.io/ksp/ You can put restrictions on departure date and travel time. What you have to do is find a transfer from Kerbin to Eve, note the arrival date, and then find a transfer from Eve to Kerbin that leaves the same day. You can add up the required DV for both legs, but that's going to be a big overestimate if you're just doing a flyby, as you'll never need to match velocity with Eve, and you can do an aerocapture when returning to Kerbin. I'd suspect that 8K DV would be more than enough.

A Kerbin year is far less than 222 days, I believe, and so if you had a trajectory that was more or less completely contained within Kerbin's orbit, it should also take less than 222 days. As for planning such a trajectory, that's a bit more difficult. I suspect that it's possible with 8K DV, but I don't know how feasible it would be to find a workable solution via trial and error. There should be a program floating around this forum that's capable of planning flyby maneuvers. I don't know if it can handle the weird case where your destination planet is also your planet of origin, but it's probably the closest to what you're looking for if you just want to go to Eve and back. The problem gets more complicated if you want to chain together multiple gravity assists, like NASA did with the Voyager missions, and I'm not aware of any existing tools that'll do that for KSP.

I recently stumbled upon http://pagmo.sourceforge.net/pagmo/index.html, which comes with implementations of some real-world trajectory optimization problems provided by the ESA. Need to spend some time digging through the code to figure out exactly what it's doing, but at a glance it seems like it could be modified without too much fuss to be used for KSP - then we could actually plan these things prior to launch rather than just hoping for the best. Maybe I'll play around with it a bit this coming weekend.

Plan and execute a mission to Eeloo that requires at least two gravity assists after leaving Kerbin's SOI (though if you re-enter Kerbin's SOI later and use that as one of your assists, that counts). The rocket you send shouldn't have enough delta-v do make it with fewer.