Jump to content

Precomputed Low-TWR Interplanetary Transfer Burns


Red Iron Crown

Recommended Posts

Interplanetary transfer burns can be tricky, especially if the vessel has a low TWR (as is often the case when using nuclear or ion engines). Manouver nodes assume instantaneous burns, so if your vessel has to do a substantially long burn to escape they become inaccurate. One of the techniques to minimize that effect is to split up the single big burn into a succession of smaller burns (sometimes called "periapsis kicking"), but that introduces its own problems:

  • - The time taken completing the interim orbits makes it hard to hit the transfer window precisely.
  • - Ejection angle changes as Kerbin revolves around the Sun, so your periapsis may not be where you want when you make the final burn.

To sidestep the above issues, I have applied Kepler's 2nd Law and the Vis-viva equation to precompute a simple series of small burns (300m/s or less) to complete before escape, applicable to any interplanetary transfer from Kerbin:

Inital Orbit: 100km circular.

Burn 1: Raise apoapsis to 658km, costing 300m/s of ΔV.
Burn 2: At next periapsis, raise apoapsis to 2,250km, costing 300m/s.
Burn 3: At next periapsis, raise apoapsis to 31,930km, costing 298m/s.
Burn 4: At next periapsis, burn to transfer, costing 20m/s plus the remainder of the transfer burn.

To hit the transfer window correctly, schedule the first burn for as close to 11 Kerbin days (66 hours) before the ideal transfer time as possible. To get the periapsis at the correct ejection angle, subtract 9.3 degrees from the computed transfer ejection angle for the first burn. It is more important to get the ejection angle correct than the time.

Another set of burns for very low TWR craft using burns of about 100m/s, gives burn times of less than two minutes even with a TWR of about 0.1:

Inital Orbit: 100km circular.

Burn 1: Raise apoapsis to 240km, costing 100m/s of ΔV.
Burn 2: At next periapsis, raise apoapsis to 419km, costing 100m/s.
Burn 3: At next periapsis, raise apoapsis to 658km, costing 100m/s.
Burn 4: At next periapsis, raise apoapsis to 987km, costing 100m/s.
Burn 5: At next periapsis, raise apoapsis to 1,471km, costing 100m/s.
Burn 6: At next periapsis, raise apoapsis to 2,250km, costing 100m/s.
Burn 7: At next periapsis, raise apoapsis to 3,708km, costing 100m/s.
Burn 8: At next periapsis, raise apoapsis to 7,409km, costing 100m/s.
Burn 9: At next periapsis, raise apoapsis to 34,650km, costing 99m/s.
Burn 10: At next periapsis, burn to transfer, costing 18m/s plus the remainder of the transfer burn.

To hit the transfer window correctly, schedule the first burn for as close to 15 Kerbin days (90 hours) before the ideal transfer time as possible. To get the periapsis at the correct ejection angle, subtract 12.7 degrees from the computed transfer ejection angle for the first burn. It is more important to get the ejection angle correct than the time.

In using these precomputed burns a few times, I have come to realize something that should have been obvious to me: Getting the correct semi-major axis is more important than getting the apoapsis correct. So ideally your Ap+Pe would be as close as you can manage to CalculatedAp+100km, especially for the final interim orbit.

Limitations/Assumptions:

  • Calculated assuming instantaneous burns, hopefully the vessel's TWR is high enough for reasonable burn times of the smaller nodes.
  • Assumed no inclination change for the transfer. No normal/antinormal burn components are considered.
  • The last interim orbit is higher than the Mun's orbit, an encounter with it could mess up your carefully laid plans.

Useful tools:

  • A transfer window calculator, such as http://ksp.olex.biz/ (simpler) or http://alexmoon.github.io/ksp/ (more complex), to calculate the ideal transfer window's time and ejection angle. There are also mods such as Transfer Window Planner or MechJeb that include such tools in game.
  • Mods for precisely setting the ejection angle of a node, such as PreciseNode, KER or MechJeb.

Finally, for those who would like to play around with their own values, here is the spreadsheet I used to calculate the above (xlsx format, please forgive the sparse formatting): MultiburnEscape.xlsx. I release this into the public domain, do with it what you will.

Edit: regex was kind enough to expand upon the original spreadsheet and make it more general purpose, get it here: MultiburnEscapeExpanded.xls

Questions, comments, or corrections are very welcome. Happy flying!

Edited by Red Iron Crown
Tidied up formatting.
Link to comment
Share on other sites

I went ahead and expanded your spreadsheet, including cells for a variable day length (hours), multiple burns beyond four, and also information for Earth (for RSS use).

Expanded Sheet

Fantastic regex, thanks for your contribution! I'm not an RSS player, but I can see that splitting up burns would be even more useful there given the higher orbital speed and greater delta-V requirements for interplanetary transfers.

The precomputed values I've done have tweaked the last interim orbit to make a whole number of Kerbin days to begin maneuvers before the intended final transfer burn, for convenience of calculating when to begin. Thanks for adding support for 24hr days as well (I really should have thought of that). :)

Link to comment
Share on other sites

Thanks for adding support for 24hr days as well (I really should have thought of that). :)
Some RSS configs (for those odd multipliers, 1.75x or 6.4x) may even use 12 or 18 hour days. Makes it easy. I contemplated computing the SOI of the body for the final burn but you also need the solar mass and the body's SMA from its parent, and I didn't want to mess up your sheet too much. Anyway...
Link to comment
Share on other sites

I think I can translate the spreadsheet into a kOS script.

I'm picturing a workflow where you create a maneuver node for an all-at-once departure burn, then run the program to generate a sequence of nodes with the final burn at the time of the input node.

Setting a node 90 hours out while you're in LKO is probably easier with a node-editor mod than with the stock +/- 1 orbit buttons, but that part can be left as an exercise for the reader for now.

Link to comment
Share on other sites

I think I can translate the spreadsheet into a kOS script.

I'm picturing a workflow where you create a maneuver node for an all-at-once departure burn, then run the program to generate a sequence of nodes with the final burn at the time of the input node.

That's a great idea. I'm not really familiar with writing kOS scripts but that sounds like a useful application of it. The values I computed above were tweaked for player convenience (whole number of Kerbin days before window, whole number of kilometers for each apoapsis), but if the nodes are being generated automatically then that's not really necessary anymore.

Setting a node 90 hours out while you're in LKO is probably easier with a node-editor mod than with the stock +/- 1 orbit buttons, but that part can be left as an exercise for the reader for now.

It's not really necessary to set more than one node at a time using the precomputed values. The only one that might not be on the current orbit is the very first node, which I'm assuming players will make when they are 11 or 15 Kerbin days from the transfer window so it shouldn't need to jump ahead much.

Link to comment
Share on other sites

It's not really necessary to set more than one node at a time using the precomputed values. The only one that might not be on the current orbit is the very first node, which I'm assuming players will make when they are 11 or 15 Kerbin days from the transfer window so it shouldn't need to jump ahead much.

That's one advantage of using the table over the kOS approach: with the kOS approach, the final node is the one you have to set by hand before auto-generating the ones closer to you. Setting a node 90 hours out is a problem with my idea, not yours.

Link to comment
Share on other sites

I see what you mean, undercoveryankee, I think I misunderstood you before. So basically in your scenario, the player would set up a node as if doing the burn all in one go at the proper time, then the kOS script would auto generate the smaller earlier nodes and adjust the final node. So yeah, you would need to set up that big node far enough in advance to leave time for all the interim burns.

Link to comment
Share on other sites

  • 2 weeks later...
I think I can translate the spreadsheet into a kOS script.

I'm picturing a workflow where you create a maneuver node for an all-at-once departure burn, then run the program to generate a sequence of nodes with the final burn at the time of the input node.

Setting a node 90 hours out while you're in LKO is probably easier with a node-editor mod than with the stock +/- 1 orbit buttons, but that part can be left as an exercise for the reader for now.

any progress with the kOS script?

Link to comment
Share on other sites

Planning precise nodes well ahead of time is a fool's errand.

The game stores nodes as something that should happen at a particular time, not on a particular point of your orbit. By the time you get to the third or fourth node, they will no longer sit anywhere near your periapsis.

However, setting nodes up as you go works reasonably well:


until obt:period > 2*60*60 { //two hours
set foo to time:seconds+eta:periapsis.
set bar to node(foo,0,0,100). //node(absolute_time,radial,normal,prograde)
add bar.
run exenode. //which would be a script that executes nodes
}

Still, the periapsis will inevitably shift a little and you burns won't be 100% precise; if you can line up 8 burns of 100m/s each and the periapsis is somewhere within ten minutes of the desired time, that's as good as it gets -- and good enough, IMO. But if you want higher precision, you'll have to correct the last maneuvers manually.

Link to comment
Share on other sites

any progress with the kOS script?

Honestly, I've kind of taken a break from making KSP things. It got to where I felt bad for just playing my career game because there were so many things I'd said I wanted to work on someday. Chances are I'll work on it whenever I want to do a multi-kick departure in a save where I'm using kOS.

- - - Updated - - -

Planning precise nodes well ahead of time is a fool's errand.

The game stores nodes as something that should happen at a particular time, not on a particular point of your orbit. By the time you get to the third or fourth node, they will no longer sit anywhere near your periapsis.

However, setting nodes up as you go works reasonably well:


until obt:period > 2*60*60 { //two hours
set foo to time:seconds+eta:periapsis.
set bar to node(foo,0,0,100). //node(absolute_time,radial,normal,prograde)
add bar.
run exenode. //which would be a script that executes nodes
}

Still, the periapsis will inevitably shift a little and you burns won't be 100% precise; if you can line up 8 burns of 100m/s each and the periapsis is somewhere within ten minutes of the desired time, that's as good as it gets -- and good enough, IMO. But if you want higher precision, you'll have to correct the last maneuvers manually.

Good point. I still want to experiment with working backward from a pre-created single-burn node (the idea being that the pre-created node is how you tell the script what the final escape orbit should be). I'll have to look at how real spacecraft compensate for errors during a long mission plan.

Link to comment
Share on other sites

I still want to experiment with working backward from a pre-created single-burn node (the idea being that the pre-created node is how you tell the script what the final escape orbit should be). I'll have to look at how real spacecraft compensate for errors during a long mission plan.

I realize I've been ambiguous. To clarifiy:

a) if you do repeated burns at periapsis, as described by my script above, the periapsis will probably shift a little, one degree or two.

B) on the last periapsis kick, the script must compensate for all errors that have occurred so far. The last burn should not fill a quota, but must be just right so that you arrive at periapsis at the desired time.

For B), the precision you can achieve depends very much on how high your last apoapsis will be. If you raise it to somewhere beyond the Mun, 0.1m/s will make a five minute difference in orbital period.

Just placing the remainder of the original node minus all previous burns will be off by a dozen m/s or so, and maybe +-10 seconds of periapsis. Personally, I'd rather just refine it myself; though a proper recalculation would be neat.

What I also cannot do is placing maneuvers at specific places of my orbit, like n degrees from prograde or at an ascending/descending node. So I have to perform the first burn myself before I can let kOS do repeated burns at periapsis. If you can do better, please share.

Link to comment
Share on other sites

  • 1 month later...

In using these precomputed burns a few times, I have come to realize something that should have been obvious to me: Getting the correct semi-major-axis is more important than getting the apoapsis correct. So ideally your Ap+Pe would be as close as you can manage to CalculatedAp+100km, especially for the final interim orbit.

Link to comment
Share on other sites

  • 3 weeks later...
It is more important to get the ejection angle correct than the time.

Ironically, this part is always giving me more trouble than the actual act of flying low TWR craft :s

I understand that ejection angle is the angle between the point of the orbit you occupy at burn start, and the full prograde (or retrograde) vector of the planet on its orbit around the sun.

But how am I supposed to carefully adjust my ejection angle without a tool to measure angles with? I mean, I realize that PreciseNode is a thing that exists, but then again, there are also mods that give you ridiculous high TWR engines that consume no fuel worth mentioning and thus render the approach you present here completely irrelevant. In the spirit of not simply saying "mod it" and thereby rendering all problems irrelevant, I'd rather ask about your recommendation for stock KSP.

What does a stock player do to get an ejection angle correct down to the decimal digit, 10 to 15 Kerbin days in advance?

Link to comment
Share on other sites

What does a stock player do to get an ejection angle correct down to the decimal digit, 10 to 15 Kerbin days in advance?

Simply put, you don't. You can get a reasonable approximation by using a physical protractor on the map screen, but it won't be as exact as using a mod like precisenode.

For pure stock, Brainlord Mesomorph's method is better, start the first burn at such a time that the initial angle to prograde is 90 degrees and thus more easily eyeballed or aligned with a straightedge.

I wrote the spreadsheet to solve a problem that I, as a stock-parts-with-info-mods player, was having; and I found it useful enough that I felt some might benefit from me sharing it. It is certainly not an all-purpose solution.

Edited by Red Iron Crown
Link to comment
Share on other sites

I see. Makes sense, I guess.

I'm really curious about how Squad is going to be addressing the whole ejection angle topic in the new interplanetary travel tutorial that's coming with 1.0. They're going to have to address it in some way, even if it's in the form of supplying a method of getting by without actually talking about ejection angles. I'm not holding my breath, but hey, maybe there will be a sort of UI improvement that will help with angles. Hope dies last, as they say :P

Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...
  • 3 weeks later...

The two obvious ways of doing the final burn have problems. Point prograde for the whole burn and you'll raise periapsis during the first half of it, squandering your carefully conserved Oberth Effect. Point at the node for the whole burn and you'll push periapsis back down into the atmosphere during the first half, losing precious speed and possibly even deorbiting.

I have found the best compromise is exactly that: Aim between the prograde direction and the node direction. Watch your periapsis carefully: If it starts to fall point closer to prograde, if it starts to climb point closer to the node. Once past periapsis, point straight prograde for the remainder of the burn to avoid steering losses. Here's an example picture (in this case I was using a 75km parking orbit and had allowed the periapsis to creep up a bit, but the general idea is visible).

Link to comment
Share on other sites

  • 2 months later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...