[HN Gopher] Bi-elliptic transfer orbit maneuver
       ___________________________________________________________________
        
       Bi-elliptic transfer orbit maneuver
        
       Author : ColinWright
       Score  : 51 points
       Date   : 2024-12-08 14:16 UTC (3 days ago)
        
 (HTM) web link (www.johndcook.com)
 (TXT) w3m dump (www.johndcook.com)
        
       | xnorswap wrote:
       | This article seems very light on equations and calculations, and
       | would be greatly enhanced by including them.
        
         | daeken wrote:
         | 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.
        
         | perihelions wrote:
         | 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 Dv you need is
         | (defun Dv (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 Dv-hohmann (r1 r2)           (+ (Dv r1 r1 r2)    ;; at
         | r1, raise apoapsis r1 -> r2              (Dv 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 Dv-bielliptic (r1 r2
         | r-inter)           (+ (Dv r1 r1 r-inter)              (Dv
         | r-inter r1 r2)              (Dv 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).
        
           | xnorswap wrote:
           | 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.
        
       | hoseja wrote:
       | Bi-elliptic can also be better for large inclination changes. The
       | catch is that coasting to the eccentric apogee takes way longer.
        
         | perihelions wrote:
         | 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...
        
       | koromak wrote:
       | 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).
        
         | montjoy wrote:
         | I'm pretty sure it's done whenever there are inclination
         | changes. Mechjeb had an option for it IIRC.
        
           | radonek wrote:
           | Absolutely. I've hardly ever done bieliptic transfer in KSP,
           | but I stick to bieliptic plane changes for almost every big
           | inclination change. Dv savings can be huge.
        
         | natosaichek wrote:
         | It should work in ksp. Its still an impulsive maneuver.
        
         | xnorswap wrote:
         | 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.
        
       | idiotsecant wrote:
       | Wow, it's completely non-intuitive that this is more efficient!
       | Neat.
        
         | daeken wrote:
         | 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.
        
           | avmich wrote:
           | 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.
        
       | GlenTheMachine wrote:
       | The Hohmann transfer is formally the most fuel efficient two-burn
       | transfer. Bi-elliptic transfers require three burns.
        
         | bell-cot wrote:
         | 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".
        
           | GlenTheMachine wrote:
           | Correct.
           | 
           | On the other hand, neither one is guaranteed to be optimal
           | for continuous thrust maneuvers, which with electric prop are
           | increasingly common.
        
           | jgsteven wrote:
           | 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.
        
       | tofof wrote:
       | 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
        
       | andrewflnr wrote:
       | > 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.
        
       | NotYourLawyer wrote:
       | I wish he'd included some intuitive or hand waving explanation of
       | why and when this is more efficient.
        
         | mota7 wrote:
         | 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).
        
       | simonjanssen wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2024-12-11 23:01 UTC)