ADR-010 — Keplerian half-ellipses for transfer arc

Status · Accepted Date · 2026-04-15 Last revised · 2026-04-29 (Slice 4 implementation note) TA anchor · §components/fly-screen · §constraints

Context

The fly screen needs to draw the spacecraft's transfer trajectory between Earth and Mars. An approximation is needed — a full n-body propagation is out of scope.

Decision

The transfer arc is computed as a Keplerian half-ellipse using the actual semi-major axis and eccentricity of the Earth-Mars Hohmann transfer ellipse. The outbound arc sweeps true anomaly ν: 0→π. The return arc sweeps ν: π→2π on a second ellipse oriented so its perihelion aligns with Earth's actual position at the return date.

Rationale

Bezier curves were the original implementation. They produced arcs that passed through the Sun, required manual tuning of control points, and broke whenever the Earth-Mars geometry changed. A Keplerian ellipse is physically correct, parameterised by the actual orbital mechanics, and never intersects the Sun. The perihelion-of-return-orbit targeting Earth's actual return position ensures the spacecraft ends at Earth's real location on the return date — not where Earth was at departure.

Alternatives considered

• Bezier curves — fast to implement; geometrically wrong; passes through the Sun in some configurations; rejected.
• Full Lambert propagation for the arc — would produce a more accurate trajectory shape; requires computing the full transfer ellipse from the Lambert solution. Acceptable future refinement; current Keplerian half-ellipse is correct to first order.

Consequences

Positive: arc is physically correct; never intersects the Sun; parametric — automatically adapts to different launch windows. Negative: the return arc is an approximation (uses same transfer ellipse as outbound, not a separate Lambert solution for the return leg). Good enough for educational purposes.

Implementation note (Slice 4, 2026-04-29)

The implementation in src/lib/mission-arc.ts realises this ADR with two distinct geometries, only one of which is a true Keplerian ellipse:

• Outbound arc (outboundArc) — exact Keplerian half-ellipse: r = a(1−e²)/(1+e·cos(ν)) swept ν: 0→π, with the perihelion direction rotated to match Earth's launch angle. ✓ matches the ADR.
• Return arc (returnArc) — parametric cosine radius profile (r = a + Δr·cos(πt)) sweeping the long-way (~321°) CCW path from Mars flyby to Earth return position. Not a strict second Keplerian ellipse with shifted perihelion as the original ADR text implied. The cosine profile gives a visually correct free-return loop that ends at Earth's actual return position, but doesn't satisfy r = a(1−e²)/(1+e·cos(ν)) for any single (a, e) pair.

Why the deviation: a strict second-ellipse return arc requires solving a second Lambert problem (Mars flyby state + Earth return position + return TOF → second transfer ellipse). The infrastructure exists (solveLambert ships in src/lib/lambert.ts since Slice 3) but adopting it would require event timing precision the simulation doesn't currently surface. The cosine profile is the prototype P03's solution and matches what the educational view needs.

If a future slice gains a need for true Keplerian fidelity on the return leg (e.g., to surface real ∆v at flyby), the path forward is: feed solveLambert(marsFlybyPos, earthReturnPos, returnTOF, μ_sun) and render the resulting ellipse via outboundArc-style ν-sweep on the returned a. Tracked as a v2 candidate.

Tests: src/lib/mission-arc.test.ts covers the outbound arc as a true Keplerian ellipse (perihelion / aphelion / midpoint radius checks) and the return arc as a "long CCW path with cosine midpoint radius A_TRANSFER" — the cosine-profile spec, not the Keplerian one.