`orbitforge transfer lambert`

Synopsis


orbitforge transfer lambert --r1 <X,Y,Z> --r2 <X,Y,Z> --tof-minutes <MINUTES> [OPTIONS]

Description

Lambert’s problem asks: given a departure position, an arrival position, and the time to travel between them, what orbit connects them?

The answer is the two velocity vectors, at departure and at arrival. Differencing them against the velocities you actually have gives the delta-v of a transfer, which is why this is the foundation of rendezvous, intercept, and phasing analysis.

Options

Parameter	Type	Unit	Default	Required	Description
`--r1`	string	km	—	Yes	Departure position as `x,y,z` in ECI.
`--r2`	string	km	—	Yes	Arrival position as `x,y,z` in ECI.
`--tof-minutes`	float	min	—	Yes	Time of flight. This is the parameter that selects which of the infinitely many connecting orbits you get.
`--long-way`	flag	n/a	—	No	Sweep the long way, through more than 180 degrees of transfer angle.
`--json`	path	n/a	—	No	Write the solution.

Worked example

A quarter-revolution transfer from 7000 km on the x-axis to 8000 km on the y-axis, in one hour:


orbitforge transfer lambert \
  --r1 "7000,0,0" \
  --r2 "0,8000,0" \
  --tof-minutes 60


Lambert short-way transfer over 90.000 deg (a = 6825.1 km):
  v1 = [4.606920, 5.853216, 0.000000] km/s (|v1| 7.448748)
  v2 = [-5.121564, -3.875268, -0.000000] km/s (|v2| 6.422470)

Reading the output

Figure	Value	Meaning
Transfer angle	90.000 deg	Angle swept between the two position vectors
Semi-major axis	6825.1 km	The connecting orbit’s size
`v1`	7.448748 km/s	Velocity required at departure
`v2`	6.422470 km/s	Velocity on arrival

Speed falls from 7.45 to 6.42 km/s because the spacecraft climbs from 7000 km to 8000 km, trading kinetic for potential energy. That is a useful sanity check: on any transfer to a higher radius the arrival speed should be lower.

The z-components are zero because both positions lie in the equatorial plane, so the transfer orbit does too. Any out-of-plane component in the inputs produces an inclined transfer, and the plane change is usually the expensive part.

Short way and long way

Two positions and a time of flight admit two distinct solutions: sweeping less than 180 degrees, or more.

Path	Selected by	Character
Short way	Default	Sweeps under 180 degrees
Long way	`--long-way`	Sweeps over 180 degrees, taking the other route around

For the same time of flight the long way traverses a greater arc, which demands a very different orbit and usually far more energy. It matters when the direct path is obstructed, when a specific arrival geometry is required, or when phasing constraints rule out the short solution.

Time of flight is what makes the problem well posed. Infinitely many orbits connect two points; specifying how long the journey takes selects one, and a shorter time of flight always demands a more energetic orbit.

Computing transfer delta-v

The command returns required velocities, not delta-v. To get the cost:

\Delta v_{\text{depart}} = \left| \mathbf{v}_1 - \mathbf{v}_{\text{initial}} \right|, \qquad \Delta v_{\text{arrive}} = \left| \mathbf{v}_{\text{final}} - \mathbf{v}_2 \right|

where $\mathbf{v}_{\text{initial}}$ is your velocity on the departure orbit and $\mathbf{v}_{\text{final}}$ is the velocity you need on the arrival orbit.

The usual workflow is to sweep time of flight, compute total delta-v for each, and take the minimum. That curve is rarely monotonic: very short flights are expensive because the transfer orbit is extreme, and very long ones can be expensive because of unfavorable arrival geometry.

Model basis: Lambert's problem

Assumptions: Two-body point-mass gravity; no perturbations; impulsive velocity changes at departure and arrival; both positions expressed in the same inertial frame at their respective times.
Validity range: Non-degenerate geometry. The solution is undefined when the two position vectors are collinear, because the transfer plane is then indeterminate. Accuracy degrades over long flight times where J2 and drag become significant.
Accuracy: Exact within two-body dynamics. Real transfers require correction for perturbations, and the delta-v computed here should be treated as a first-order estimate for trade studies rather than a burn specification.
Reference: Classical solution of Lambert's problem; see Battin, An Introduction to the Mathematics and Methods of Astrodynamics.

Frames and epochs

Both positions must be in the same inertial frame. The command performs no frame conversion and has no epoch input: it is pure geometry, and it is your responsibility to ensure the two vectors are consistently expressed.

This is the most common way to get a wrong answer here. Mixing an ECI departure with an ECEF arrival produces a confident solution to a problem you did not intend, and nothing in the output will indicate it.

orbitforge transfer lambert