Visual walkthrough — Terminal descent — velocity vector alignment, touchdown constraints
This is the picture-first companion to the parent note. If you want the "why four constraints" story, read that first; here we care only about how the acceleration command is derived.
Step 1 — Draw the problem: two dots and two arrows
WHAT. Picture the lander as a single dot (its center of mass). Right now it sits at a place we call ("where it is") moving with a velocity we call ("how fast, and in what direction"). At the landing instant we want it at a place (the pad) with a velocity (straight down, tiny).
WHY. Every guidance problem is "get from this state to that state." A state here means a dot AND its arrow together. We drew both because the whole difficulty is that we must match two things at once, not one.
PICTURE. The red arrow is the current velocity — long and tilted (danger). The short black arrow at the pad is the target velocity — short and vertical (safe).

Step 2 — Name the clock: time-to-go
WHAT. Let be the current time and the landing time. Define the time-to-go It is simply "how many seconds are left." At the start it is a few seconds; at touchdown it is .
WHY this and not ? The physics of "how much can I still change my velocity" depends only on time remaining, not on what time it happens to be. Using makes the equations clean: the finish line is always at .
PICTURE. A shrinking horizontal bar: full at the start, empty at touchdown.

Step 3 — Guess a trajectory shape. Why "acceleration"?
WHAT. We control the vehicle by choosing its acceleration — the rate at which the velocity arrow changes. The physics is Newton's law, rewritten for our point mass: where means "acceleration" (the second time-derivative of position), is what the engine commands, and is gravity pulling down.
WHY acceleration and not "just pick a path"? Because the engine produces thrust, and thrust ÷ mass is an acceleration. We cannot teleport the dot; we can only push it. So the natural unknown is .
WHY a constant-ish acceleration? Ask: what is the simplest push that can hit both a target position and a target velocity? A single fixed direction (a straight shove) can aim only one of them. Let's count degrees of freedom in the next step — that count decides everything.
PICTURE. The velocity arrow being bent by a small acceleration arrow, second by second, into a new direction.

Step 4 — Count the freedom: why constant acceleration is not enough
WHAT. Suppose acceleration is a constant for the whole . Then the standard "constant-acceleration" motion equations (the ones for a ball thrown under gravity) give, at the finish:
Annotate the velocity line:
WHY count? We have two targets to hit per axis: final position and final velocity. That's two equations. A constant gives us one free vector (three numbers, one per axis) — but per axis it's one unknown for two equations. One knob, two locks. It cannot generally satisfy both.
PICTURE. A single fixed acceleration bends the path — but the endpoint arrow comes out wrong (overshoots the target velocity) even when the endpoint dot lands right.

Step 5 — Add a knob: let acceleration ramp linearly
WHAT. Allow the acceleration to vary linearly with time. Measuring a fresh clock from now () to touchdown ():
WHY linear and not curved? It is the simplest shape with enough freedom. One extra parameter () buys exactly the one extra equation we were missing in Step 4 — no more, no less. Adding curvature would give unused freedom.
PICTURE. The acceleration plotted against time is now a sloped line (start value , slope ), not a flat one.

Step 6 — Integrate and match the four boundary conditions
WHAT. "Integrate" just means: add up the little pushes to see how velocity and position build over time. Ignoring for a moment (we fold it back at the end), integrate :
Now demand the two targets be hit:
- Velocity target:
- Position target:
Two vector equations, two unknowns . Solving (done in the VERIFY block) gives the acceleration we should command right now, which is :
WHY re-attach ? The dynamics say . Our integrals above assumed pure with no gravity. To make the real world (which does have ) follow that gravity-free plan, the command must contain a to cancel it. The engine then produces exactly — gravity is inside, don't add it twice.
PICTURE. Two curves converge: the position curve lands on and its slope (velocity) lands on at the same instant.

Step 7 — Velocity vector alignment: watch the arrow rotate
WHAT. Choose the target velocity vertical: with – m/s. Look at the horizontal part of the command. With , the horizontal shaping term is
WHY does the velocity arrow become vertical? As , the factor grows, so any leftover sideways speed gets an ever-stronger opposing push. It is squeezed to zero right at touchdown — so the velocity arrow rotates from tilted to straight-down. This is the "velocity vector alignment" the parent note demands, and it is closely related to how Proportional Navigation nulls line-of-sight rotation.
PICTURE. A fan of velocity arrows at successive instants, tilting more and more upright, the last one pointing straight down at the pad.

Step 8 — The degenerate case: blows up
WHAT. Look again at the two coefficients: and . As these explode toward infinity. The commanded acceleration (and thus thrust) would demand more than the engine can give.
WHY floor it? Physically you cannot correct an arbitrarily large error in arbitrarily little time — that would need infinite force. The floor keeps the demand finite and lets the Attitude Control & Inner Loop keep up.
PICTURE. The coefficient plotted vs. : a curve rocketing to the sky near zero, with a red "floor" line where we clamp it.

The one-picture summary
Everything above, compressed: the current state (dot + tilted red arrow) is bent by a linearly ramping acceleration into a curved trajectory that lands on the pad with a short vertical arrow, exactly as — while the coefficients and do the position-fix and velocity-shape jobs, and cancels gravity so the engine just outputs .

Recall Feynman retelling — say it out loud in plain words
We have a dot moving with an arrow, and we want it to reach a pad moving with a tiny downward arrow. To hit two things at once — the place and the arrow — one steady push isn't enough (one knob, two locks). So we let the push change smoothly over the remaining time: a start value and a ramp — two knobs for two locks. When we add up (integrate) those pushes and force the finish to match both targets, out pop the numbers 6 and 2: the erases the distance gap, the bleeds the speed toward the target, and because the world has gravity while our plan didn't, we subtract so the engine's real thrust exactly equals the command — never add gravity twice. As the clock runs out, the factor grows and forces any sideways speed to zero, so the arrow swings upright right as we touch. But near zero those factors explode, so we clamp the clock and switch to a gentle drop for the last moment.
Recall Quick self-test
Why can't a constant acceleration hit both position and velocity? ::: It gives one knob per axis but there are two targets per axis (place and speed); we need a second free parameter, so we ramp the acceleration linearly. Where do the numbers 6 and 2 come from? ::: From the and in the position/velocity integrals when the two boundary conditions are solved for the current acceleration . Why does the velocity arrow become vertical near the end? ::: The horizontal shaping term grows as , crushing any sideways speed to zero at touchdown. What blows up as and how is it handled? ::: The coefficients and blow up; we floor or hand off to a constant-velocity drop, and cap thrust. Do you add gravity on top of when sizing thrust? ::: No — the term is already inside ; the engine produces exactly .