Protractor, Kerbal Engineer, Kerbal Alarm Clock, MechJeb and navigation...

[Fourjays]

Hi,

I'm fairly new to KSP (been playing about a month now) and am still learning some things. One thing I am particularly struggling with is navigation... in practice at least. Having watched Scott Manley's video on navigating between planets I felt like I've got a good grasp on it. Using the online calculator and manoeuvre nodes I managed to get a distant encounter, but it took a lot of effort. So I started trying mods (Protractor, Kerbal Engineer Redux, MechJeb and Kerbal Alarm Clock) that will make it easier, but after many tests over the last few weeks, I've been left with more questions than answers...

1) The Protractor mod gives two angles that are "countdowns" and as in Scott's videos this makes sense. One is the angle of Kerbin relevant to the target planet, the other is the angle during my orbit that I need to begin the burn to escape and basically I ideally wait for them to both be 0'. I have used this in conjunction with the manoeuvre nodes and can get an encounter (albeit not a close one, but I could correct it during the journey). So today I gave Kerbal Engineer a go after noticing that it seems to show the same information, plus loads more. In Kerbal Engineer, I can see the "Intercept Angle" nearly matches up with the first value in Protractor (it is out by a degree). However, I can't see any angle that "matches" with the second angle in Protractor, including the one labelled "Ejection Angle". Why are these values different? What am I not understanding? And what are the other angles displayed in Kerbal Engineer used for?

2) Kerbal Alarm Clock has a feature for adding alarms for transfer windows, which I used in a game a week ago. When the alarm eventually went off, Protractor was showing that I was 2'+ past the point at which I should transfer (even with several hours advance warning set on the alarm). Why was there such a difference? And does it matter?

3) Is there a way to find out how much TWR or Delta-V I'll need at various stages of a mission other than trial and error? Or is that like asking how long a piece of string is? Loads of mods can tell me what those values currently are (and what they'd be on other planets), but nothing tells me what I need to get into orbit, or get from Kerbin to the Mun, or perform a transfer from Kerbin to Eve. Trial and error doesn't bother me so much with the short hops I've been doing so far, but I'd hate to do a mission to Jool, only to get swallowed up because I under-guesstimated the amount of fuel required to achieve orbit.

4) In MechJeb 2 is there a way to get it to display the angles needed for navigation in the same way that Protractor/Kerbal Engineer do (counting down)?

Thanks

[SkyRender]

1. With the advent of maneuver nodes, the omega provided by Protractor is a lot less useful than it once was. You can just muck about with maneuver nodes to find the correct ejection angle.

2. The only real impact of being a few degrees off of optimal timing is that you burn a bit more fuel to "catch up" with your target time. It's pretty similar in principle to how there's about a billion intercepts possible of the Mun from Kerbin orbit, but some of them are more fuel-efficient than others for getting you where you want to go.

3. There is: consult a system map. Here's one I cooked up.

Keep in mind that those are average values displayed. There is no absolute dV requirement for anything, since your starting conditions, TWR, piloting skills, and a number of other factors are what determine your required dV. When in doubt, have a fudge factor of 10% for your fuel margins at minimum.

4. No idea; never used MechJeb.

Edited May 1, 2013 by SkyRender

[Scotius]

Sadly, i'm not an expert in interplanetary astrogation. I can easily get to both moons and Duna, but thats about all for now. Missions to Eve and Jool are a series of trials and errors involving a lot of eyeballing, and Dres frankly scares me with it's huge inclination But as for point 3:

http://www.skyrender.net/lp/ksp/system_map.png

Try to use this.

Wow. I've been ninja'ed by the very author. Now you have it straight from the source.

Edited May 1, 2013 by Scotius
Being too late.

[maltesh]

Basically, both protractor and kerbal alarm clock give countdowns by by assuming that all the planets move in equatorial, circular orbits at constant velocities. Only Kerbin actually does. If you want an alarm that is closer to what Protractor is eventually going to show, you may want to set an alarm that hits a week or two ahead of the prediction, and then set a new alarm that may produce a more accurate number when the alarm hits zero.

Is it that big of a deal? My feeling is "Not really," as SkyRender mentions. If you were measuring phase angles by putting an actual plastic protractor on the screen, you'd probably wind up being off by more, and ultimately, the mod is intended to help get you close to your target, the rest is your piloting.

[Noticeably FAT]

I use:

This calculator to get an optimum phase/ejection angle, and approximate dV requirement.

MechJeb to find my current phase angle

The equation in this thread to find the time to the next optimum phase angle

Kerbal Alarm Clock to let me know when that phase angle is coming up (I started using KAC before it had phase angle alarms, I still don't use them because it's more fun to break out the slide rule and calculate the time manually)

All that gets me close to the required phase angle, and close to the required dV. At that point I eyeball the ejection angle and set up a maneuver node. I start out with the dV value Olex's calculator gave me, and futz with it from there. I've gotten an intercept within ~200m/s each of the half dozen or so times I've tried it. The only times I've had to to mid-course corrections is when I tried periapsis kicks (I didn't do them well) and once when I wasn't paying close attention and was going to end up in a highly inclined orbit that I didn't want (though I still would have ended up in an orbit).

[tavert]

SkyRender, do you have a single central thread for your system map? Some of your numbers need revision. Dres takes closer to 600 m/s more than Kerbin escape to transfer to, and about 1500 m/s to capture at. And if you can capture into a circular low Mun orbit for only 210 m/s from a LKO Hohmann transfer, I'd like to see how. It's usually closer to 260-280 for me.

Protractor and alarm clock might be using different methods to calculate the windows, not sure.

I think the phase angles were added to MechJeb2 somewhat recently, you might have to select the target planet first and make a custom info window. The numbers there aren't in countdown form, but you can easily determine the number you're waiting for from ksp.olex.biz.

All of these methods are really only good for near-circular and low-inclination planets. For Moho, Dres, and Eeloo especially, phase angles are going to be a ways off. In the MechJeb2 maneuver planner, select the planet as a target then make maneuvers for "transfer to another planet" then "fine-tune closest approach" and you should get much closer, as it's using the actual elliptic trajectory, the real minimum distance, and a real Lambert solver for the fine-tune option.

[Eric S]

Basically, both protractor and kerbal alarm clock give countdowns by by assuming that all the planets move in equatorial, circular orbits at constant velocities. Only Kerbin actually does.

Very true. Last time I went to Duna, I botched the estimate for how much delta-V I'd need, so needed an almost perfect return transfer. Checking on the transfer when protractor said to would have resulted in a required course correction that was more than just minor. However, I noticed that most of the course correction came down to hitting Kerbin's orbit at the same time kerbin was there. By waiting a while, I was able to almost eliminate the need for a course correction. And by a while, I'm talking a good 15 or 20 degrees worth of phase angle. Those numbers that come out of those two are estimates only because of this.

[SkyRender]

The thread for my system map was eaten by the unintended forum purge, unfortunately. Also, you have to remember some important facts about that map. One: the values are all averages; as I noted, there are no absolute values there, and your results can and will vary depending on your parameters. Two: no planet save Kerbin has a perfectly circular orbit, ergo you are not guaranteed to need the average dV it takes to get to it (Dres in particular can be pretty wildly off-base if you start from a phase angle that puts it on the far end of its orbit from the sun). And three: the values are meant as a guideline only. You should never base your entire flight plan off of averages.

As for Munar circularizing, it does take close to 260m/s if you're coming in very low. If you come in high, it can take barely 150m/s (but your landing will take a lot more). Similarly, coming in from a low orbit, you can land on the Mun at a meaningful discount on that 640m/s (and return to that low orbit for a similarly discounted amount). In those cases, you're just trading off when you expend the dV, for the most part.

[tavert]

Averages based on what though? It'd be nice if you could make a spreadsheet or something that showed based on orbital parameters where you were getting these numbers from.

I like to time my transfers so I get to my target near its AN or DN, so I need very little if any inclination correction. I guess I should compare the 1-burn transfer that goes a longer distance to a 2-burn transfer when the target's closer. What I'd really love to see (and have been considering putting together) would be a proper Lambert-based almanac of transfer windows. Could maybe even do a comparison of 1-burn transfer delta-V to 2-burn solutions that use the ecliptic projection then an inclination correction.

There's no point to ever circularizing at a higher altitude than the lowest stable orbit if your mission plan involves transferring in and out of SoI and/or landing, as potential energy is pretty much useless... IMO it would be more useful for transfer data to be relative to the lowest stable orbit. Raising and lowering orbits within a single SoI is a much easier calculation than ejections to real Lambert-solution transfers.

For those of us doing challenges to take minimalist ships as far as possible, it's nice having an accurate guideline for doing our design, and an unpleasant surprise when that guideline ends up way off the mark.

[SkyRender]

What you're asking for is technically feasible, but not as a single comprehensive chart. Rather, it would require a series of separate charts for each planet-to-planet/moon interaction. That's pretty far outside the scope of a delta-V map, which is meant to give a general idea of what sorts of expenditures you'll be looking at so you can design something powerful enough to complete your desired mission. There are others better-suited to such a task than myself, particularly in regards to the sort of time it would take.

[tavert]

There was one thing I was asking for, which was can you share how you got your numbers. What I'm musing about possibly working on would be a much more complicated transfer almanac. Someone had been working on a fancy porkchop plotter for KSP around the 0.16 timeframe which would be a good place to start, but I don't think he kept working on it and I'm not sure whether the post or what he accomplished so far are now victims of the purge...

[Fourjays]

Thanks for the help everyone. That map in particular is going to be really useful.

[tomf]

Doint the pork chop chart and working out the delta-vs for non-Hohmann transfers looks pretty hard, but calculating the numbers shown on charts isn't too bad. I typed it up but decided it deserved a thread of it's own.

http://forum.kerbalspaceprogram.com/showthread.php/27171-Calculating-interplanetary-delta-v

[superm18]

Pure stock player here!

Practice makes perfect, i've gone through a dozen saves or so and the only way (i to be good at it is without help from mods!

[magnemoe]

I always use the phase angle for burn in protractor as an hint of where to put my maneuverer node and nudge it until I get an intercept or at least an close pass.

Also remember you can add an second node along the projected path this is very useful for target out of orbital plane like Moho or Eeloo