Bi-elliptic transfer orbit maneuver | Hacker News Reader

Bi-elliptic transfer orbit maneuver

johndcook.com

64 pointsColinWright25 comments

The direction change from first to second elipse does indeed produce the hook the author visualized. I'm not sure why he had trouble finding examples of this diagram already existing for suitably scaled orbits.

https://www.researchgate.net/profile/Sergey-Zaborsky/publica... https://media.springernature.com/lw685/springer-static/image...

From https://www.researchgate.net/figure/Scheme-of-bi-elliptic-tr... https://link.springer.com/article/10.1007/s40295-015-0043-3

> The meaning of the dotted orange curve is different in this plot.

I really think it would have been better to have two different colors for the two transfer orbits. Changing the meaning of part of your notation like that is needlessly confusing, and misses the chance to show the full shape of both transfer orbits as well.

This article seems very light on equations and calculations, and would be greatly enhanced by including them.

I have a simple implementation of a delta-V calculator for bielliptic transfers here if you want a quick look at the underlying math: https://github.com/daeken/OrbitalRingsBook/blob/main/space-t... -- the DeltaVForBiEllipticTransfer function. (The calculator widget in the book doesn't use it, but I was primarily using it for getting high orbits in an effort to minimize plane change delta-V for another calculation and this code inherited it. Also, you can actually play with the widget in action here, though again it's only using Hohmann transfers due to the low fuel requirements in play: https://ors.daeken.dev/space-travel.html)

Happy to explain the math in more detail, but the code is -- I think -- pretty self-explanatory.

Edit to add: this function doesn't calculate the initial lift to the higher orbit; that'd be the difference between the speed of your circular orbit and the perigee speed at the higher orbit.

There wouldn't be much to add. In a one-mass system, the speed of a satellite at any point is a function solely of the radial distance r: v^2 = 2/r - 1/a. The semimajor axis a characterizes the orbit; is positive for an elliptical orbit; and is the the arithmetic mean of the closest and farthest points on that ellipse—i.e. the periapsis and apoapsis.

If you're at one of either the closest- or farthest- points, at distance r, and the opposite one is s, this reduces to

    (defun speed-at (r s)
      (sqrt
       (- (/ 2.0 r)
          (/ 2.0 (+ r s)))))

And; if you have an orbit burn at one of these points that's co-linear with your direction of motion—something that simply expands or contracts the periapsis or apopasis, as is the question here—then velocity addition is a one-dimensional scalar sum. Concretely: if you're in an orbit defined by the peri- and apo- distances (r,s), and you want an orbital maneuver, at r, that either increases or decreases the opposite distance from s to s*, the Δv you need is

    (defun Δv (r s s*)
      (abs (- (speed-at r s)
              (speed-at r s*))))

That's all the math needed for calculating delta-v's for the maneuvuers in the OP post. I.e., the Hohmann transfer between two circular orbits, of radius r1 and r2, is

    (defun Δv-hohmann (r1 r2)
      (+ (Δv r1 r1 r2)    ;; at r1, raise apoapsis r1 -> r2
         (Δv r2 r1 r2)))  ;; at r2, raise periapsis r1 -> r2

And the bielliptic transfer is a sequence of three of these. I think it's

    (defun Δv-bielliptic (r1 r2 r-inter)
      (+ (Δv r1 r1 r-inter)
         (Δv r-inter r1 r2)
         (Δv r2 r-inter r2)))

(I've left out the dimension-ful scaling factors; if you want a concrete calculation for a real object, you can scale everything throughout (inside the roots) by G*M, which is i.e. 398600 [km^3/s^2] for Earth).

I'm not sure why you think that numbers don't add anything, this example from wikipedia is helpful: https://en.wikipedia.org/wiki/Bi-elliptic_transfer#Example

Including illustrative numbers on the diagram in the article would be helpful to show the difference.

The second image seems to be a ballistic capture leveraging weak stability boundaries in a 3 body problem.

It's the kind of transfer used by many spacecrafts to get to the moon nowadays (hohmann transfers are only the most efficient in 2 body problems).

Further reading: https://en.wikipedia.org/wiki/Weak_stability_boundary#Applic...

Edit: Also https://www.gg.caltech.edu/~mwl/publications/papers/lowEnerg...

Bi-elliptic can also be better for large inclination changes. The catch is that coasting to the eccentric apogee takes way longer.

That's a key use. A search keyword is "supersynchronous transfer"—the common case of (bielliptic) transfers to geosynchronous orbit, which first go above GEO for an inclination change.

https://www.esa.int/ESA_Multimedia/Images/2022/10/Supersynch...

The Hohmann transfer is formally the most fuel efficient two-burn transfer. Bi-elliptic transfers require three burns.

Which is an issue because re-starting a good-sized* rocket engine in 0g is non-trivial, and the penalty for failure tends to be "mission failed, vehicle lost".

*Meaning "large enough for major orbital maneuvers".

Correct.

On the other hand, neither one is guaranteed to be optimal for continuous thrust maneuvers, which with electric prop are increasingly common.

For Earth orbiting satellites using their own on-board propulsion with storable propellant, hardly anyone actually does these transfer orbit maneuver sequences in just two-burns. (edit: For example, for geosynchronous transfer orbit) the delta-V is almost always broken up into 4 to 6 maneuvers of decreasing size (to improve targeting accuracy at the end). The launch vehicle upper stage usually does the first burn to go from the low circular orbit to the elliptical transfer orbit.

For these onboard main engines, number of starts is not a concern.

Back when some geosynchronous satellites used solid motors there would be one huge maneuver at apogee to get nearly all the way to GEO (e.g. the Hughes/Boeing 376 spinners). The uncertainty in performance on these maneuvers was quite large so correction maneuvers were always planned afterwards.

I wish he’d included some intuitive or hand waving explanation of why and when this is more efficient.

The hand-waving explanation: The slower you're going, the easier (cheaper) it is to change direction. And for eliptical orbits, the outer-most part of the orbit is where you're going slow.

So to make a drastic change in direction (aka, a very different orbit):

1. First burn to move far away from the center of the orbit so that you're going very slow.

2. Then burn to make a large change in direction (orbit).

3. Then wait until you cross your desired final orbit, and burn again to close it.

The tradeoff is that these types of orbit change are very slow (because you want to be going very slow for the middle burn, which means you take ages to get there).

Oh boy something new to try in KSP. Funny I've never seen anyone do this, maybe the imperfect simulation means its never more efficient (in-game).

I’m pretty sure it’s done whenever there are inclination changes. Mechjeb had an option for it IIRC.

Absolutely. I've hardly ever done bieliptic transfer in KSP, but I stick to bieliptic plane changes for almost every big inclination change. Δv savings can be huge.

It should work in ksp. Its still an impulsive maneuver.

The transfer times are a killer.

It's only more efficient when the ratio in orbits is around 12 or higher, and then you have to go even higher than that to get more efficient, and takes at least twice as long to complete the transfer.

I'm not sure there's even such a ratio in KSP, even Moho to Jool is less than that.

So you'd need to be in a very artificial scenario for it to be more efficient, and the extra time would be tedious (even at full warp) compared to a regular transfer.

Wow, it's completely non-intuitive that this is more efficient! Neat.

For an intuitive example of where this is more efficient, consider plane changes. The delta-V for a plane change is 2 * sin(angular_change/2) * speed

The higher an orbit is, the slower you're going at apogee. If you're doing a large plane change, going even slower will save you a *ton* of delta-V, so you can transfer up to a much higher orbit, plane change at apogee, and then transfer down to your desired final orbit.

That's by far the most useful place for bielliptic transfers, not just going from one orbit to another on the same plane.

In the limit, going from first space velocity V1 (low circular orbit) to second space velocity (parabolic speed) V2 = sqrt(2) * V1 takes delta V = (sqrt(2)-1) * V1, then at infinity you do plane change to the opposite with expending zero delta V, then come back and return to the same orbit, only the opposite direction (largest speed change) spending again delta V = (sqrt(2)-1) * V1. Comparing this total of 0.82 * V1 to spending 2 * V1 if you do that on the spot - just reversing the orbital velocity in place - shows the benefit.

Might help to have some animations, equations, and data and to not reuse graphical elements when they have different meanings.

Bi-elliptic transfers changed my KSP rendezvous procedures so much. No more waiting 5-6 orbits for a Hohmann!

Reply on news.ycombinator.com