Skip to content

ENH: Control and Guidance to land a rocket on the ground (GFOLD) #209

Description

@brunopinto900

Hello,

Is your feature request related to a problem? Please describe.

Me and my colleagues want to implement several algorithms to land a rocket on the ground (GFOLD) is one of the solutions. Is this possible with the current state of this repo?

Thank you.

Activity

  1. changed the title [-]Control and Guidance[/-] [+]ENH: Control and Guidance to land a rocket on the ground (GFOLD)[/+] on Nov 2, 2024
  2. added
    EnhancementNew feature or request, including adjustments in current codes
    on Nov 2, 2024
  3. hahahuy commented on Apr 8, 2026

    @hahahuy

    Relationship to issue #952 (powered descent physics)

    I've opened issue #952 which proposes the simulation physics layer that GFOLD (this issue) would need as a foundation:

    #952 — Proposal: powered descent / retropropulsion module
    #952

    The split in scope:

    #952 (physics) #209 (guidance — this issue)
    What it adds New u_dot_powered_descent ODE derivative, descent_motor phase in FlightPhases, motor mass accounting during descent GFOLD fuel-optimal guidance law (CasADi or custom solver)
    Dependency None — standalone physics Requires #952 to be testable end-to-end
    Integration New Flight parameters: descent_motor, descent_trigger, guidance_schedule Produces the guidance_schedule (thrust vs. time) that #952 replays

    The key design decision discussed in #952: guidance is pre-solved offline and replayed as a thrust schedule during integration — no optimizer inside the ODE loop. This keeps Monte Carlo runs fast (~0.1 s/trajectory) while still supporting optimal landing.

    Would love to coordinate if there's active work on #209 to make sure the physics API (#952) exposes what the guidance layer needs.

  4. ting-hong-shieh commented on Aug 14, 2026

    @ting-hong-shieh

    The dynamics prerequisite is now being discussed in #952. I suggest keeping GFOLD as a guidance layer that produces a schedule, with RocketPy's powered-descent implementation responsible for executing that schedule.

    The first interface can be solver-neutral:

    • input: initial state, target state, vehicle limits, thrust bounds, mass model, and time bounds;
    • output: timestamped thrust magnitude/direction and ignition/shutdown schedule; and
    • status: optimal, infeasible, iteration/solver failure, with diagnostics that do not depend on one optimizer.

    CasADi or another optimizer can remain an optional backend behind that interface. The core package should still be able to import and run ordinary Flight simulations without the optimization dependency installed.

    Acceptance should include one fixed feasible benchmark with a known objective range, one infeasible constraint set, schedule serialization, and replay of the schedule through the #952 dynamics to verify the terminal state within stated tolerances. Guidance tests should not pass merely because the optimizer returned success; the replayed physics result is the relevant end-to-end check.

    I recommend waiting until #952 has a stable event and thrust-command API before choosing public GFOLD classes. Once that prerequisite exists, I can help define the benchmark fixture and schedule protocol as a separate first milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ControllersControlling rocket flight methodsEnhancementNew feature or request, including adjustments in current codesHelp wantedExtra attention is needed

    Projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions