Chapter 27: Guidance, Navigation, and Control

"Plans are worthless, but planning is everything." — Dwight D. Eisenhower

Overview

Every previous chapter of this book has built a capability. The rocket equation says how much delta-v you carry (Chapter 3); orbital mechanics says where a burn will send you (Chapter 10); attitude dynamics says how to point (Chapter 14); orbit determination says how to know where you are (Chapter 13). But a capability is not a flight. A rocket sitting on the pad with full tanks, a perfect trajectory printed on paper, and a working star tracker will still tumble into the sea unless something, thousands of times a second, reads where the vehicle is, compares it to where it should be, and moves the engines and thrusters to close the gap. That something is the subject of this chapter: the closed loop that actually flies the vehicle. We call it guidance, navigation, and control — GN&C — and it is the nervous system of every rocket, satellite, and lander ever flown.

Here is the single idea to hold onto before all the machinery: a rocket is not aimed and fired like an arrow. An arrow is an open-loop system — you release it, and from that instant physics alone decides where it lands; a gust of wind is a miss you cannot take back. A rocket is the opposite. It is steered continuously, correcting every deviation as it happens, so that the wind gust, the slightly-off engine, the sloshing propellant, and the thousand other insults reality delivers are all measured and cancelled before they can accumulate into failure. The flight is not in the plan; it is in the correcting. This is why GN&C exists, why it is the same discipline whether the vehicle is a launch booster or a Mars lander or a thermostat on your wall, and why the field has its own beautiful answer to the fact that space is an unforgiving environment (theme 2): you survive an unforgiving world not by planning perfectly, but by correcting relentlessly.

In this chapter, you will learn to:

• See GN&C as one closed loop — sense, estimate, decide, actuate — and say what "closed-loop" buys you.
• Recognize navigation as onboard state estimation, and reuse the Kalman filter of Chapter 13 as its engine.
• Explain what guidance computes, from an ascent pitch program to powered explicit guidance and targeting.
• Read the PID control law term by term, hand-trace a control loop, and reason about why loops oscillate.
• Assemble real sensors and actuators into the integrated loop, and see why deep-space missions must fly it alone.

Learning Paths

🚀 Space Enthusiast: Read 27.1 for the big picture (the loop that flies the rocket), then 27.4 (the PID loop — the one idea here you will see everywhere, from drones to cruise control) and 27.6 (the "seven minutes of terror," the most dramatic story in the book). You can skim the math of 27.2 and 27.3.

📐 Engineering Student: Read all of it and do both hand-traces — the scalar Kalman predict–update in 27.2 and the PID loop in 27.4 — by hand. Those two calculations, plus the targeting cutoff in 27.3, are the working core of flight software. This chapter unifies Chapters 13 and 14 into one system; treat it as the capstone of the "how do we fly it?" thread.

🎮 KSP Player: You have flown this loop by hand every launch. Your gravity-turn pitch program is open-loop guidance (27.3); MechJeb's "ascent guidance" is closed-loop PEG; SAS holding an attitude is a control loop (27.4) fighting disturbance torques; and "no signal, probe on its own" is autonomy (27.6).

🛰️ Industry Prep: GN&C is a career. Focus on 27.2 (the navigation filter, the daily tool of every nav team), 27.4 (control law design and tuning), and 27.5 (sensor-to-actuator integration and loop architecture). Your Mission Design Checkpoint writes the GN&C approach for your mission — a real MDR line.

27.1 GN&C: the closed loop that flies the rocket

Start with the three questions a flying vehicle must answer, continuously, forever, or die. Where am I, and how am I moving and oriented? Where do I need to be, and what path takes me there? What must I command my engines and thrusters to do to get on that path and stay on it? Those three questions are the three letters of GN&C, and each has its own name.

Definition (navigation). Navigation is the onboard determination of the vehicle's current state — its position, velocity, orientation, and rotation rate — together with an estimate of how uncertain that determination is. It answers "where am I, how am I moving, and how sure am I?" It is the sensing-and-estimating front end of the loop, and it is the flight-time cousin of the orbit determination of Chapter 13 and the attitude determination of Chapter 14.

Definition (guidance). Guidance is the computation of where the vehicle should go and how — the desired trajectory or the desired steering command that will take it from its current state (supplied by navigation) to its target (an orbit, a rendezvous point, a landing site). It answers "where do I need to go, and what path gets me there?" Guidance is the decision-making brain of the loop.

Definition (control). Control is the generation of the actuator commands — engine gimbal angles, thruster firings, reaction-wheel torques — that make the vehicle actually follow the path guidance chose, driving the difference between desired and actual state (the error) toward zero despite disturbances. It answers "what do I command the hardware to do, right now?" Control is the muscle-and-reflex of the loop.

Navigation, guidance, control: know, decide, act. Run them once and you have processed a single instant. The magic is in running them over and over, each cycle feeding the next, in a ring:

   ┌───────────┐   estimated state    ┌───────────┐   desired state    ┌───────────┐
   │NAVIGATION │─────────────────────►│ GUIDANCE  │───────────────────►│  CONTROL  │
   │ "where    │  (position, velocity,│ "where do │  (target state, or │ "what do  │
   │  am I?"   │   attitude — and how │  I go and │   a steering        │  I command│
   │ estimate  │   sure: a covariance)│  by what  │   command)          │  the      │
   │  the state│                      │  path?"   │                     │ actuators?"│
   └─────▲─────┘                      └───────────┘                     └─────┬─────┘
         │ sensor data                                     actuator commands  │
         │ (IMU, star tracker,                             (TVC, thrusters,   │
         │  GNSS, radar, DSN ranging)                       reaction wheels)  │
         │                                                                    ▼
         │                      ┌────────────────────────────┐
         └──────────────────────┤    THE VEHICLE (the plant) │◄─── disturbances
                                │   moves under real physics  │     (wind, gravity,
                                └────────────────────────────┘      slosh, offset thrust)

The ring is the whole point, and it has a name.

Definition (closed-loop control). Closed-loop control (feedback control) is a control scheme in which the actual output of the system is measured and fed back to compute the error, and the command is continuously adjusted to reduce that error. Its opposite is open-loop control, which issues a pre-planned command without measuring the result and correcting for it. Closed-loop control is what lets a system reject disturbances and tolerate imperfect models; open-loop control cannot, because it never learns that anything went wrong.

The difference is not academic; it is the difference between a rocket that flies and one that does not. Consider steering a car down a straight road with your eyes closed. You could, in principle, work out in advance exactly how to hold the wheel — that is an open-loop plan. In practice you would be in the ditch within seconds, because the tiniest unmodeled effect (a crown in the road, a gust, a soft tire) accumulates with nothing to check it. Open your eyes and you steer effortlessly, not because your plan is better but because you are closing the loop — sensing the drift and correcting it continuously. A rocket climbs through wind shear, sloshing propellant, and thrust that is never perfectly aligned with its center of mass; no open-loop plan could survive that. The loop survives it, by design.

🚪 Threshold Concept: flying is error-correction, not aiming. The reorganizing idea of this whole chapter — and arguably of all of engineering that touches the real world — is that you do not achieve a goal by computing the perfect action in advance and executing it blindly. You achieve it by continuously measuring the gap between where you are and where you want to be, and acting to shrink that gap, forever. The plan is a starting guess; the loop is what actually flies the vehicle. Once you see this, a dozen things fall into place: why a rocket needs sensors at all (an arrow does not); why the same three boxes appear in a satellite, a self-driving car, a furnace thermostat, and your own hand reaching for a cup; why "it worked in simulation" is never enough (the loop must reject the disturbances the simulation lacked); and why Eisenhower's line at the head of this chapter is a control-theory statement in disguise. The plan is worthless the instant reality deviates from it. The planning — the machinery that re-decides every cycle — is everything.

There is real beauty here, and it is our theme that orbital mechanics is beautiful (theme 3) wearing an engineering coat. The very same Newtonian physics we spent Part II admiring — $\mathbf{F} = m\mathbf{a}$ for translation, its rotational twin $\mathbf{M} = \mathbf{I}\dot{\boldsymbol\omega} + \dots$ for attitude (Chapter 14) — becomes, inside a feedback loop, something new: not just a description of how the world evolves, but a lever we close our hands around to bend that evolution to our will. The feedback loop that holds a Mars lander steady in a crosswind is mathematically the same object as the one that holds the temperature in your house, and both are the same $F=ma$ you learned in Chapter 2, now steered. That a thermostat and a Moon landing are the same idea is the kind of unification physics keeps handing us, and it never stops being lovely.

🔄 Check Your Understanding 1. Match each of navigation, guidance, and control to the question it answers: "what do I command the actuators?", "where am I and how sure?", "where do I go and by what path?" 2. In one sentence, what does closing the loop (feedback) buy you that an open-loop plan cannot? 3. Why would a rocket flown purely open-loop — a perfect pre-computed steering program, no sensors — almost certainly fail, even if the trajectory were computed flawlessly?

Answers

1. Navigation → "where am I and how sure?"; guidance → "where do I go and by what path?"; control → "what do I command the actuators?". 2. It lets the system measure and reject disturbances and model errors — it corrects for whatever the plan got wrong, which an open-loop command can never do because it never checks the result. 3. Because unmodeled disturbances (wind, slosh, thrust misalignment, small mass errors) accumulate with nothing to cancel them; without feedback, a tiny initial deviation grows unchecked until the vehicle departs its trajectory. The flight lives in the correcting, not the plan.

27.2 Navigation: state estimation (the Kalman filter as the engine)

Navigation must answer "where am I?" — but recall the hard truth of Chapter 13: no instrument measures the state. Sensors report shadows of it — an acceleration, a star direction, a radar range — each indirect and noisy. Turning that stream of imperfect clues into a single best running estimate of the full state is the navigation problem, and it has a name of its own.

Definition (state estimation). State estimation is the process of computing a best estimate of a system's state — and the uncertainty of that estimate — from a stream of indirect, noisy measurements combined with a dynamical model of how the state evolves. For a spacecraft the state is the full dynamical description: position and velocity (the orbit, Chapter 8) and orientation and angular velocity (the attitude, Chapter 14). Navigation is real-time state estimation running onboard, every cycle, for the whole mission.

Notice the two ingredients baked into that definition: measurements (what the sensors report now) and a dynamical model (how physics says the state should evolve between measurements). An estimator that used only measurements would throw away everything it knows about how orbits and rigid bodies move; one that used only the model would drift away from reality as small errors compound. The art is to blend them — and the optimal way to blend them is a piece of mathematics you have already built.

🔗 Connection: this is the "N" in GN&C, and you built it in Chapter 13. The navigation engine of every spacecraft is the Kalman filter — the recursive predict-then-update estimator that Chapter 13 §13.6 defined, derived, and demonstrated. This chapter does not redefine it; it uses it. Chapter 13 owns the filter; here we simply drop it into the loop as the box labelled "navigation," exactly as that chapter promised it would. If the predict–update cycle, the Kalman gain, or the scalar update rule are not fresh in your mind, reread §13.6 now — everything below assumes it.

Let us recall just enough to plug it in. The Kalman filter carries two things forward: the state estimate and its uncertainty. In the predict step it propagates the estimate forward with the dynamics — the orbit propagator of Chapter 12, the integrated gyro rates of Chapter 14 — and the uncertainty grows, because extrapolation is guesswork and the real world adds little unmodeled accelerations (the process noise). In the update step a measurement arrives, and the filter forms a weighted blend of prediction and measurement in proportion to their relative confidences; the uncertainty shrinks, because information was added. The weight is the Kalman gain. For a single scalar quantity, the rule Chapter 13 derived is

$$ K = \frac{\sigma_{\text{pred}}^2}{\sigma_{\text{pred}}^2 + \sigma_{\text{meas}}^2}, \qquad \hat{x}^+ = \hat{x}^- + K\,(z - \hat{x}^-), \qquad (\sigma^+)^2 = (1 - K)\,\sigma_{\text{pred}}^2, $$

with $\hat{x}^-$ the prediction, $z$ the measurement, and $\sigma$ the respective standard deviations. Chapter 13 worked a pure update; navigation runs predict then update, over and over, so let us trace one full cycle in a flight setting — a lander coasting on its inertial sensor between radar fixes.

Worked Example: one predict–update cycle of a lander's altimeter navigation. A lunar lander's navigation filter last fixed its altitude a few seconds ago as $1{,}000\ \text{m}$ with an uncertainty of $\sigma = 20\ \text{m}$ (variance $400\ \text{m}^2$). Since then it has coasted, propagating altitude forward by double-integrating its inertial measurement unit (IMU) — the accelerometer-and- gyro package that dead-reckons motion. Dead reckoning drifts, so the predict step adds process noise $Q = 500\ \text{m}^2$ to the variance: $$\sigma_{\text{pred}}^2 = 400 + 500 = 900\ \text{m}^2 \;\Rightarrow\; \sigma_{\text{pred}} = 30\ \text{m},$$ and suppose the propagated ("predicted") altitude is $\hat{x}^- = 1{,}000\ \text{m}$. Now the landing radar returns a fresh altitude measurement $z = 1{,}090\ \text{m}$ with $\sigma_{\text{meas}} = 10\ \text{m}$ (variance $100\ \text{m}^2$). Blend them. The gain is $$K = \frac{900}{900 + 100} = 0.9,$$ so the filter trusts the sharper radar nine-tenths of the way. The updated estimate is $$\hat{x}^+ = 1{,}000 + 0.9\,(1{,}090 - 1{,}000) = 1{,}000 + 81 = 1{,}081\ \text{m},$$ and the updated uncertainty is $$(\sigma^+)^2 = (1 - 0.9)(900) = 90\ \text{m}^2 \;\Rightarrow\; \sigma^+ = 9.49\ \text{m}.$$ Sanity check. The fused uncertainty, $9.49\ \text{m}$, is smaller than both inputs — the prediction's $30\ \text{m}$ and even the radar's $10\ \text{m}$ — exactly the inverse-variance miracle of §13.6: $1/90 = 1/900 + 1/100$, i.e. $0.01111 = 0.00111 + 0.01000$ ✓. Every measurement, however noisy, leaves the lander strictly more sure of its altitude than it was before. The predict step gave back some uncertainty ($20 \to 30\ \text{m}$) as the price of coasting; the update more than repaid it. Run this cycle a few times a second all the way down, and you have navigation. $\blacksquare$

def predict(x, var, process_noise):
    """Coast the estimate forward; uncertainty grows by the process noise."""
    return x, var + process_noise          # (dead-reckoned x unchanged here; only var grows)

def update(x_pred, var_pred, z, var_meas):
    """Fuse a prediction with a measurement (the Chapter 13 scalar Kalman update)."""
    K = var_pred / (var_pred + var_meas)   # Kalman gain in [0, 1]
    x_upd = x_pred + K * (z - x_pred)       # blend toward the sharper source
    return x_upd, (1 - K) * var_pred, K

x, var = 1000.0, 20.0**2                    # last fix: 1000 m, sigma 20 m
x, var = predict(x, var, 500.0)             # coast on the IMU: var 400 -> 900
x, var, K = update(x, var, 1090.0, 10.0**2) # landing-radar fix at 1090 m, sigma 10 m
print(round(K, 2), round(x, 1), round(var**0.5, 2))
# Expected output:
# 0.9 1081.0 9.49

The real navigation filter is the same idea with the six-to-thirteen-number spacecraft state in place of one altitude, the nonlinear gravity and rigid-body dynamics in place of the trivial coast, and the extended Kalman filter (EKF) — which linearizes the model at each step — in place of the scalar rule. We will not re-derive it (that is Chapter 13's linear-algebra territory, honestly flagged there), but the logic is unchanged: predict with physics and grow the uncertainty; update with a sensor and shrink it; let the gain arbitrate. And the sensors it fuses are exactly the hardware of the last two chapters — the star tracker and gyros of Chapter 14, the GNSS receiver and ground tracking of Chapter 13, the deep-space ranging and Doppler of Chapter 26.

⚠️ Common Misconception: "the IMU already tells you where you are, so why filter?" An IMU measures accelerations and rotation rates, not position and attitude. To get position you integrate acceleration twice, and to get attitude you integrate rate once — and every integration turns the sensor's small bias and noise into an error that grows without bound. A pure inertial navigator drifts metres, then kilometres, then hopelessly; the same drift that afflicts a gyro-only attitude estimate in §14.4. The IMU is a superb short-term memory of motion and a terrible long-term one, so it is always paired with absolute fixes — star trackers, GNSS, radar, ground tracking — through the Kalman filter, which uses the smooth high-rate IMU for the predict step and resets its accumulating drift with each absolute update. Filtering is not optional polish; it is what keeps the estimate from running away.

🔄 Check Your Understanding 1. What are the two ingredients a state estimator blends, and what goes wrong if you use only one? 2. In the worked cycle, the uncertainty went $20 \to 30\ \text{m}$ (predict) then $30 \to 9.49\ \text{m}$ (update). Explain each change in one phrase. 3. Why must an IMU be paired with an absolute sensor rather than navigating on its own?

Answers

1. It blends measurements (indirect, noisy, but absolute) with a dynamical model (physics of how the state evolves). Measurements-only throws away known dynamics and is noisy; model-only drifts as small errors compound. 2. Predict: coasting on the model adds process noise, so uncertainty grows. Update: a measurement adds information, so uncertainty shrinks (below both inputs, by inverse-variance addition).
2. An IMU measures acceleration and rate; integrating them to position/attitude turns bias into unbounded drift, so it needs periodic absolute fixes (star tracker, GNSS, radar) to reset the accumulating error.

27.3 Guidance: computing the path

Navigation says where you are. Guidance decides where you should go and how to get there. If navigation is perception, guidance is intention — the layer that turns a mission objective ("reach a $200\ \text{km}$ circular orbit," "land on that spot," "rendezvous with that station") into a concrete desired trajectory or steering command for the control layer to execute. Guidance comes in two broad flavors, and the history of rocketry is largely the story of moving from the first to the second.

The older flavor is trajectory following: compute a good path once, on the ground, store it, and fly it. The classic example is the ascent pitch program — the schedule of "tilt this many degrees at this many seconds" that shapes a launch vehicle's gravity turn (Chapter 4). Early rockets flew a pitch program largely open-loop: the vehicle tilted on a timer, trusting that if it followed the stored angles it would end up roughly where intended. Even today, a booster's first phase — through the dense lower atmosphere and maximum dynamic pressure (Chapter 5) — often follows a mostly pre-planned attitude profile, because down there you want to hold a near-zero angle of attack to limit aerodynamic loads and not let a clever guidance law command an aggressive turn that tears the vehicle apart. Guidance sometimes means restraint.

The newer, more powerful flavor is explicit (closed-loop) guidance: don't follow a stored path — recompute the optimal path from where you actually are to the target, every cycle. Once a launch vehicle is above the sensible atmosphere, it can steer freely, and the guidance question becomes an optimization: of all the ways to burn the remaining propellant, which one reaches the exact target orbit using the least propellant (or in the least time)? The algorithm that answers this in real time for ascent has a name.

Definition (powered explicit guidance). Powered explicit guidance (PEG) is a closed-loop ascent guidance method that, each cycle, uses the current navigated state and the target orbit to compute the optimal thrust direction and the engine cutoff time that will reach the target with minimum propellant — then continuously recomputes as the vehicle flies, automatically absorbing dispersions (an underperforming engine, an off-nominal atmosphere) that a stored trajectory could not. It descends from the calculus of variations: the propellant-optimal steering in a uniform gravity field is the linear tangent law, in which the tangent of the thrust pitch angle varies linearly with time.

We will not derive the linear tangent law — it belongs to optimal control theory, one level of mathematics above this book, and we flag that honestly rather than fake it. But its content is graspable: there is a single best way to point the thrust as you climb, it bends smoothly from more horizontal to more vertical (or the reverse) over the burn, and PEG's job is to keep solving for that optimum and for when to shut down as the real vehicle deviates from nominal. The payoff of doing this closed-loop is enormous: a rocket whose engine is running $2\%$ hot, or whose earlier stage dropped it a little low and slow, still reaches the exact target orbit, because PEG simply recomputes the cutoff and steering to compensate. The path is not sacred; the target is.

At the heart of any explicit guidance is a simple, powerful bookkeeping quantity: the velocity-to-be- gained, the vector difference between the velocity you need at the target and the velocity you have now. Guidance points the thrust to drive this vector to zero and commands cutoff the instant it reaches zero. Let us compute the cutoff timing for a stage nearing orbit, which is the crispest piece of guidance arithmetic we can do by hand.

Strategy first. Navigation hands guidance the current speed; guidance knows the target speed at cutoff; the difference is the velocity still to be gained. Divide that by how fast the engine is adding speed (its thrust acceleration) and you get a first estimate of the time to cutoff. But the vehicle is getting lighter as it burns, so its acceleration rises, and the true cutoff comes a little sooner than the constant-acceleration guess — a correction the rocket equation supplies exactly.

Worked Example: when does guidance command engine cutoff? An upper stage must reach an insertion speed of $7{,}800\ \text{m/s}$. Navigation reports its current speed as $7{,}200\ \text{m/s}$, so the velocity still to be gained is $$v_{\text{go}} = 7{,}800 - 7{,}200 = 600\ \text{m/s}.$$ The stage now masses $m = 30{,}000\ \text{kg}$, its engine produces $F = 600{,}000\ \text{N}$ of thrust at exhaust velocity $v_e = 3{,}400\ \text{m/s}$ ($I_{sp} \approx 347\ \text{s}$; Chapter 16). Its current thrust acceleration is $$a = \frac{F}{m} = \frac{600{,}000}{30{,}000} = 20\ \text{m/s}^2.$$ A first, constant-acceleration estimate of the time to cutoff is $$t_{\text{go}} \approx \frac{v_{\text{go}}}{a} = \frac{600}{20} = 30\ \text{s}.$$ But the stage burns propellant at $\dot m = F/v_e = 600{,}000/3{,}400 = 176.5\ \text{kg/s}$, losing real mass as it goes, so its acceleration climbs and the true cutoff is sooner. The rocket equation (Chapter 3) gives the exact mass that must remain: $v_{\text{go}} = v_e \ln(m/m_f)$, so $$\frac{m}{m_f} = e^{600/3{,}400} = e^{0.1765} = 1.193 \;\Rightarrow\; m_f = \frac{30{,}000}{1.193} = 25{,}150\ \text{kg},$$ meaning $30{,}000 - 25{,}150 = 4{,}850\ \text{kg}$ of propellant must burn, which at $176.5\ \text{kg/s}$ takes $$t_{\text{go}} = \frac{4{,}850}{176.5} = 27.5\ \text{s}.$$ Sanity check. The rocket-equation time ($27.5\ \text{s}$) is a little less than the naive constant-acceleration time ($30\ \text{s}$), exactly as it should be because the acceleration rises through the burn — the vehicle covers the last of its $v_{\text{go}}$ faster than the first. Real PEG makes this same computation every cycle and updates it; when $t_{\text{go}}$ falls to zero, it commands cutoff — and the stage is in orbit. $\blacksquare$

import math

v_target, v_now = 7800.0, 7200.0   # m/s
F, m, ve = 600_000.0, 30_000.0, 3400.0

v_go = v_target - v_now                       # velocity still to be gained, m/s
t_naive = v_go / (F / m)                       # constant-acceleration estimate, s
mdot = F / ve                                  # propellant flow, kg/s
m_final = m / math.exp(v_go / ve)              # rocket-equation mass at cutoff, kg
t_go = (m - m_final) / mdot                     # true time to cutoff, s
print(round(v_go), round(t_naive, 1), round(t_go, 1))
# Expected output:
# 600 30.0 27.5

Guidance also steers the direction of the burn, not just its duration: it orients the vehicle so the thrust points along the velocity-to-be-gained vector, then holds that attitude with the control loop and the reaction wheels or gimbal of the next sections. For a maneuver in orbit — a rendezvous (Chapter 10), an interplanetary injection (Chapter 11) — the target velocity comes from solving Lambert's problem ("I am here, I want to be there at time $T$; what velocity do I need?"), which Chapter 13 §13.3 showed is the same solver read as a targeting tool. Guidance is where the orbital mechanics of Part II becomes a live command.

📜 From History: the guidance computer that went to the Moon. Guidance is the oldest "software" problem in spaceflight. The Apollo Guidance Computer, built at the MIT Instrumentation Laboratory (later Draper Lab) under Charles Stark Draper, ran the navigation filter (a Kalman filter — one of its first flight uses) and the ascent, translunar, and descent guidance for every Apollo mission, in roughly $2\ \text{KB}$ of writable memory and $36\ \text{KB}$ of rope-core program store — a millionth the memory of a modern phone. Its guidance for the lunar descent recomputed the throttle and steering all the way down, and it famously shed low-priority tasks to protect the guidance when it was overloaded during Apollo 11's landing — the "1202 alarm" we dissect in this chapter's first case study. The lesson that founded the discipline: on a vehicle, the guidance must keep running no matter what, because the ground is too far away to help in time. That is the seed of §27.6.

🔄 Check Your Understanding 1. Distinguish trajectory-following guidance from explicit (closed-loop) guidance. Which one lets a rocket still reach the exact target orbit after its engine underperforms, and why? 2. What is the velocity-to-be-gained, and what two commands does guidance derive from it? 3. In the cutoff example, why is the rocket-equation cutoff time ($27.5\ \text{s}$) shorter than the constant-acceleration estimate ($30\ \text{s}$)?

Answers

1. Trajectory-following flies a pre-computed stored path; explicit guidance recomputes the optimal path from the current state to the target every cycle. Explicit guidance (PEG) compensates for an underperforming engine because it re-solves for the cutoff and steering that still reach the target, rather than blindly following a path the vehicle can no longer match. 2. It is the vector difference between the velocity needed at the target and the current velocity; guidance derives the thrust direction (point along it) and the cutoff time (when it reaches zero). 3. Because the stage loses mass as it burns, its thrust acceleration rises, so it gains the last of the $600\ \text{m/s}$ faster than the constant-acceleration estimate assumes.

27.4 Control: feedback and the PID loop

Guidance has now handed control a target — a desired attitude to hold, a desired thrust direction, a desired descent rate. Control's job is to make it so against a vehicle that is buffeted, imperfectly modeled, and never quite where it should be. It does this by the oldest and most widely used trick in all of feedback engineering: measure the error, and command an actuator effort built from three views of that error — where it is now, where it has been, and where it is heading.

Definition (PID controller). A PID controller computes its actuator command $u$ from the error $e$ (the desired value minus the measured value) as the sum of three terms — Proportional, Integral, and Derivative: $$u(t) = K_p\,e(t) + K_i \int_0^t e(\tau)\,d\tau + K_d\,\frac{de(t)}{dt}.$$ The proportional term reacts to the present error, the integral term to the accumulated past error, and the derivative term to the predicted future error (its rate of change). The gains $K_p, K_i, K_d$ are tuned to make the loop fast, stable, and accurate.

Take the three terms one at a time, because each fixes a specific failing of the others.

• Proportional ($K_p\,e$) is the workhorse: push in proportion to how far off you are. Big error, big correction; small error, gentle correction. On its own, proportional control has two problems. First, it can leave a permanent steady-state error: if a constant disturbance (gravity on a hovering lander, a steady offset torque) must be opposed, a pure-P controller can only produce a correction when there is an error, so it settles at whatever nonzero error is just large enough to generate the needed push — it "droops." Second, pushed hard (high $K_p$), it overshoots and can oscillate.
• Integral ($K_i \int e\,dt$) cures the droop. It accumulates the error over time, so as long as any error persists, the integral term keeps growing and keeps pushing harder — until the error is driven to exactly zero. The integral is the controller's memory and its conscience: it refuses to accept a standing offset. Its cost is lag and a failure mode called integral windup (the accumulator charging up huge while an actuator is saturated), which real controllers must guard against.
• Derivative ($K_d\,\dot e$) adds foresight and damping. It responds to how fast the error is changing, so it eases off before the vehicle overshoots the target and pushes back against fast swings. It is the shock absorber that lets you turn $K_p$ up for speed without the loop ringing. Its cost is sensitivity to sensor noise, since differentiating a noisy signal amplifies the noise.

Present, past, future — reflex, memory, foresight. To feel how they combine, and why loops oscillate, nothing beats tracing one by hand. We will control a single pointing angle with a simple model: the control output is a commanded corrective rate, the angle updates by that rate each step, and a constant disturbance keeps trying to push the angle off target — precisely the situation of a steady solar-pressure torque or a thrust misalignment (Chapter 14).

Worked Example: hand-tracing a control loop, and watching it droop. Let the pointing angle be $\theta$ (degrees), the setpoint $\theta_{sp} = 0$, and the error $e = \theta_{sp} - \theta = -\theta$. Each second ($\Delta t = 1\ \text{s}$) a disturbance drives the angle up by $w = +1^{\circ}$, while the controller commands a corrective rate $u = K_p\,e$. The angle updates as $$\theta_{n+1} = \theta_n + (u_n + w)\,\Delta t = \theta_n + (K_p\,e_n + 1).$$ Use proportional only, $K_p = 0.5$, starting on target at $\theta_0 = 0$:

step $n$	$\theta_n$	error $e_n = -\theta_n$	command $u_n = 0.5\,e_n$	$\theta_{n+1} = \theta_n + u_n + 1$
0	0.00	0.00	0.00	1.00
1	1.00	−1.00	−0.50	1.50
2	1.50	−1.50	−0.75	1.75
3	1.75	−1.75	−0.875	1.875
4	1.875	−1.875	−0.9375	1.9375

The angle climbs and settles at $2^{\circ}$, never returning to zero. Why $2^{\circ}$? At steady state the angle stops moving, so $u + w = 0$, i.e. $K_p\,e_{ss} + 1 = 0$, giving $e_{ss} = -1/K_p = -2$ and $\theta_{ss} = 2^{\circ}$. This is the proportional controller's droop: it can only fight the $1^{\circ}/\text{s}$ disturbance by holding a $2^{\circ}$ standing error large enough to generate the exact opposing rate. A bigger $K_p$ would shrink the droop but never erase it — and, as we will see, push it too high and the loop overshoots instead. $\blacksquare$

Now add the integral term to kill that droop. Keep $K_p = 0.5$, add $K_i = 0.5$, so the command is $u_n = K_p\,e_n + K_i \sum_{k=0}^{n} e_k\,\Delta t$ (the running sum of past errors):

step $n$	$\theta_n$	$e_n$	$\sum e$	$u_n = 0.5\,e_n + 0.5\sum e$	$\theta_{n+1}$
0	0.00	0.00	0.00	0.00	1.00
1	1.00	−1.00	−1.00	−1.00	1.00
2	1.00	−1.00	−2.00	−1.50	0.50
3	0.50	−0.50	−2.50	−1.50	0.00
4	0.00	0.00	−2.50	−1.25	−0.25
5	−0.25	0.25	−2.25	−1.00	−0.25

The error is driven to zero by step 4 (with a small overshoot to $-0.25^{\circ}$ after), and the integral term settles near $-1$ — precisely the steady push needed to cancel the $+1^{\circ}/\text{s}$ disturbance with no standing error. That is the integral doing exactly its job: remembering the accumulated miss until the miss is gone. The small overshoot past zero is the price; a derivative term ($K_d\,\dot e$) would sense the fast approach to zero and ease off early, damping that overshoot — the shock absorber that lets you keep the loop both quick and calm.

Here is the payoff that makes a control engineer smile, and it is our theme that orbital mechanics is beautiful (theme 3) again. Look at what P and D together do to the vehicle's equation of motion. A proportional term produces a restoring effort proportional to displacement — that is a spring. A derivative term produces an effort proportional to rate — that is a damper. So a P+D controller wraps the vehicle in a virtual mass–spring–damper: it forces the error to obey $\ddot e + 2\zeta\omega_n \dot e + \omega_n^2 e = 0$, the exact damped-oscillator equation of a pendulum or a car suspension, with the spring stiffness set by $K_p$ and the damping set by $K_d$. Feedback lets us synthesize physics we wish the vehicle had: we cannot change its mass, but we can make it behave like a mass on a spring of our choosing, critically damped so it settles fast without ringing. The same second-order differential equation that Chapter 2's physics described is now something a controller manufactures on purpose.

🐛 Find the Error. An engineer wants the pointing loop above to settle faster, and reasons: "The droop is $e_{ss} = -1/K_p$, so if I just make $K_p$ huge, the steady error vanishes and the response is lightning-fast. Set $K_p = 3$." On this discrete loop ($\theta_{n+1} = \theta_n + K_p e_n + 1$, with $e_n = -\theta_n$), what actually happens, and what is the real fix for the droop?

Answer

The update becomes $\theta_{n+1} = \theta_n - K_p\theta_n + 1 = (1 - K_p)\theta_n + 1$. With $K_p = 3$ the multiplier is $(1 - 3) = -2$: the error is multiplied by $-2$ every step and grows without bound, alternating sign — the loop is unstable and the vehicle oscillates apart. Stability here needs $|1 - K_p| < 1$, i.e. $0 < K_p < 2$; the loop is well behaved only for modest gains. Cranking $K_p$ does not erase the droop, it destabilizes the loop. The correct cure for steady-state droop is the integral term (as the second trace showed), which drives the error to zero without the runaway gain — and a derivative term to damp the transient. High proportional gain buys speed only up to the stability limit, then it bites. "More gain" is the classic beginner's mistake in control.

🔧 Engineering Reality: real loops are messier than the law. The clean PID equation hides a great deal that flight software must handle. Loops run at a fixed rate (tens of hertz for a big booster's attitude loop, hundreds to thousands for agile inner loops), so the integral and derivative become the discrete sum and difference we hand-traced, and the loop rate must comfortably beat the fastest disturbance. Actuators saturate (a gimbal has a maximum angle, a wheel a maximum torque), so the controller must limit its output and stop the integral from winding up while saturated. Sensor noise forces filtering of the derivative term. And a rocket's dynamics change through flight — it grows lighter, its center of mass shifts, its slosh modes move — so the gains are scheduled, retuned continuously against flight conditions rather than fixed. Tuning a loop to be fast, stable, and robust to all of this, and proving it stable (with gain and phase margins, a linear-control-theory tool one level beyond this book), is much of what a GN&C engineer actually does.

🔄 Check Your Understanding 1. Say in one phrase what each of the P, I, and D terms responds to (present/past/future error), and the specific failing each one fixes. 2. Why does a pure proportional controller leave a steady-state "droop" against a constant disturbance, and which term erases it? 3. In the mass–spring–damper picture, which PID gain plays the spring and which plays the damper?

Answers

1. P responds to the present error (reflex; provides the main correction but can droop and overshoot); I to the accumulated past error (memory; erases steady-state droop, at the cost of lag/windup); D to the error's rate of change, i.e. the predicted future (foresight; adds damping to stop overshoot, at the cost of noise sensitivity). 2. Because P produces a correction only when there is an error, so against a constant disturbance it must hold a nonzero error just big enough to generate the opposing effort; the integral term erases it by accumulating until the error is exactly zero. 3. $K_p$ is the spring (restoring effort $\propto$ displacement); $K_d$ is the damper (effort $\propto$ rate).

27.5 Sensors → estimation → actuation, integrated

We have met the three boxes; now watch them run as one machine, wired to real hardware. A single trip around the loop — for, say, an upper stage holding its commanded burn attitude — goes like this.

Sense. The vehicle's sensors report. The IMU streams accelerations and body rates at high rate (hundreds of hertz); a star tracker delivers an absolute three-axis attitude quaternion every second or so; sun and Earth sensors give coarse always-available references; a GNSS receiver (in Earth orbit) or DSN ranging and Doppler (in deep space, Chapter 26) fix position; and near a surface, a landing radar or terrain-relative navigation camera measures altitude and ground-relative motion. None of these is the state; each is a shadow of it (§13.1).

Estimate. The navigation filter (§27.2) — the extended Kalman filter — fuses this heterogeneous stream into one best estimate of the full state and its covariance: predict forward on the IMU and the dynamics, update on each absolute fix, weight everything by its trust. The gyro's smooth drift is reset by the star tracker's absolute fix, exactly the sensor-fusion architecture of §14.4 — the same optimal blend, now running live.

Decide. Guidance (§27.3) compares the estimated state to the target and computes the desired attitude and the velocity-to-be-gained; control (§27.4) computes the error between the desired attitude and the estimated attitude and runs its PID law to command actuator efforts.

Actuate. The commands drive the muscle. For a thrusting vehicle, the primary actuator is thrust vector control (TVC) — gimbaling the engine a few degrees so its thrust line points slightly off the center of mass, producing a steering torque (Chapter 16). For fine attitude control without spending propellant, reaction wheels trade momentum with the body; for large slews and for dumping the momentum the wheels accumulate, thrusters and (in low orbit) magnetorquers apply external torque — all the actuators of §14.5, now driven by the control law. Then the vehicle moves, the sensors read the new reality, and the loop turns again, tens to thousands of times a second, for the whole flight.

The loops are usually nested (cascaded): a slow outer guidance loop (updating the target path every second or few) wraps a faster attitude loop (holding the commanded orientation, tens of hertz) which wraps a still-faster rate loop (damping body rates, hundreds of hertz). Each inner loop is fast and simple enough to be provably stable; each outer loop treats the inner loop as a reliable actuator. This layering is how a system with millisecond reflexes and minute-scale intentions is built from PID blocks that each do one job well.

One quantitative check ties the actuator side to the propulsion of Part III: does the steering authority suffice?

Worked Example: does the gimbal have enough control authority? A booster's single engine produces $F = 750{,}000\ \text{N}$ of thrust and can gimbal up to $\delta = 5^{\circ}$; the engine mount sits $L = 12\ \text{m}$ below the vehicle's center of mass. Deflecting the thrust by $\delta$ throws a sideways component $F\sin\delta$ that, acting on the moment arm $L$, produces a control torque $$M_c = F\,\sin\delta \times L = 750{,}000 \times \sin 5^{\circ} \times 12 = 750{,}000 \times 0.0872 \times 12 \approx 7.85\times10^{5}\ \text{N·m}.$$ Is that enough? Compare it to a worst-case disturbance torque — say a $1\%$ lateral thrust misalignment (a plausibly large build tolerance), which off the same arm gives $$M_d = 0.01 \times F \times L = 0.01 \times 750{,}000 \times 12 = 9.0\times10^{4}\ \text{N·m}.$$ Sanity check. The units are newton-metres throughout (a force times a length), a torque — good. The control authority exceeds the disturbance by a factor $M_c/M_d \approx 7.85\times10^{5}/9.0\times10^{4} \approx 8.7$, a healthy margin: the gimbal can not only cancel the misalignment but retain roughly $7/8$ of its range for steering and gust rejection. Had the ratio come out near or below $1$, the vehicle would be uncontrollable — the disturbance would exceed what the actuator could fight — and the design would have to grow the gimbal range, move the engine, or trim the disturbance. Control authority is a requirement you size, exactly like a delta-v or power budget. $\blacksquare$

🔗 Connection: this chapter is the knot that ties Part II and Part IV together. Look back at what fed in. The state being estimated is the orbit of Chapter 8 plus the attitude of Chapter 14. The estimator is the Kalman filter of Chapter 13. The sensors are the star trackers, gyros, and GNSS of Chapters 13–14 and the deep-space tracking of Chapter 26. The actuators are the reaction wheels, thrusters, and magnetorquers of Chapter 14 and the gimbaled engines of Chapter 16. GN&C invents almost no hardware of its own; it is the architecture that makes all of it act as one purposeful system. That is why this chapter sits where it does — after you have met every piece, it shows you the wiring.

🔄 Check Your Understanding 1. Put these in loop order and name each box's job: reaction wheel, extended Kalman filter, star tracker, PID law, guidance target. 2. Why are GN&C loops usually nested (a slow outer loop around a fast inner loop) rather than one loop? 3. In the gimbal example, what would it mean physically if the control-authority ratio $M_c/M_d$ came out less than 1?

Answers

1. Sensor: star tracker (measures absolute attitude) → estimator: extended Kalman filter (fuses sensors into state + uncertainty, "navigation") → guidance target (what state we want) → PID law (control: error → command) → reaction wheel (actuator that applies the torque) → back to the vehicle and sensors. 2. Because different jobs need different speeds: a fast inner loop damps body rates and holds attitude (and is simple enough to prove stable), while a slower outer loop updates the path/target; each outer loop treats the inner as a trustworthy actuator, which keeps the whole system stable and modular.
2. The worst-case disturbance torque would exceed the maximum control torque — the vehicle would be uncontrollable about that axis, unable to hold or correct its attitude, and the design would have to be changed (more gimbal range, longer arm, or a smaller disturbance).

27.6 Autonomy and the "seven minutes of terror"

Everything so far assumed the loop runs onboard. Why not run guidance from the ground, where the computers are bigger and a room full of experts can watch? For a satellite in low Earth orbit, the ground is partly in the loop — controllers plan maneuvers and upload commands (Chapter 31). But even there, the fast inner loops must be onboard, because a signal to the ground and back takes too long for a reflex. And as you go farther out, the ground drops out of the loop entirely — not by choice, but by physics. The reason is the finite speed of light.

Definition (autonomy). Autonomy, in spaceflight, is a vehicle's capacity to run its own guidance, navigation, and control loop — to sense, decide, and act — without waiting for commands from the ground. The degree of autonomy a mission requires is set largely by the communication light-time delay: when a round-trip signal takes longer than the time available to react, the decision must be made onboard, because help from Earth would arrive too late to matter.

Do the arithmetic that forces the issue. Radio travels at the speed of light, $c \approx 3.0\times10^{5}\ \text{km/s}$. When Mars is near a typical landing-season distance of about $2.5\times10^{8}\ \text{km}$ from Earth, a one-way signal takes

$$ t_{\text{one-way}} = \frac{2.5\times10^{8}\ \text{km}}{3.0\times10^{5}\ \text{km/s}} \approx 830\ \text{s} \approx 14\ \text{minutes}, $$

so a round trip — a question to Earth and an answer back — is about 28 minutes. Now consider what a Mars lander must do on arrival. It hits the top of the atmosphere at some $5.5\ \text{km/s}$ and must go from there to a soft touchdown in about seven minutes — the entry, descent, and landing (EDL) sequence that Chapter 34 treats in full. Line those numbers up and the whole drama is in the mismatch:

$$ \underbrace{7\ \text{minutes}}_{\text{time to land}} \;\ll\; \underbrace{14\ \text{minutes}}_{\text{time for one word to reach Earth}}. $$

By the time the signal announcing "atmospheric entry has begun" reaches Earth, the spacecraft has already been on the surface — alive or dead — for about seven minutes. Every decision of the descent — when to deploy the parachute, when to separate the heat shield, when to ignite the retro-rockets, how to steer to the target, when to cut the lander loose on its cables — must be made by the vehicle itself, in real time, correctly, the first time, with Earth reduced to a helpless spectator watching a fourteen-minute-old recording of a fate already sealed. This is the famous "seven minutes of terror," and it is the purest statement in all of spaceflight of our theme that space is an unforgiving environment (theme 2): there is no pause, no do-over, and — across a hundred million kilometres of vacuum — no one to call.

🚪 Threshold Concept: distance forces intelligence onboard. The reorganizing idea of autonomy is that when the round-trip light-time exceeds your reaction time, control must live on the vehicle — not as a design preference, but as an inescapable consequence of relativity's speed limit. This single inequality explains the shape of the entire field. It is why a LEO satellite can lean on the ground but a Mars lander cannot; why the Apollo computer had to shed tasks and keep flying rather than phone home; why deep- space probes carry elaborate onboard fault protection that can diagnose a problem, safe the vehicle, and wait, all by themselves; and why the farther and faster a mission goes, the smarter it must be without us. Autonomy is not the science-fiction dream of a clever robot; it is the cold arithmetic of distance divided by the speed of light, and it makes the closed loop of this chapter not merely useful but the literal difference between a spacecraft and a very expensive meteor.

Autonomy is therefore a spectrum, set by that arithmetic. A crewed station in LEO can be tightly ground-supervised, with the round-trip under a second. A GEO comsat runs its own attitude control continuously but takes maneuver plans from the ground. A deep-space probe navigates and safes itself for hours or days between contacts. A Mars EDL is fully autonomous by necessity for its critical minutes. And the trend of the whole industry is toward more autonomy everywhere — autonomous rendezvous and docking (Chapter 10), autonomous propulsive landing of a booster back onto its pad (Chapter 22; Chapter 38), autonomous collision avoidance — because a loop that closes onboard is faster, cheaper to operate, and does not break when the link does.

Making the loop autonomous raises the stakes on the computer that runs it. It must be radiation- hardened to survive the particle environment without a crash (Chapter 26), and it must be extraordinarily reliable, because there is no engineer to reboot it in the seven minutes that matter — the redundancy- and-testing discipline of Chapter 32. The autonomous GN&C loop is, in the end, where every theme of this book comes due at once: the tyranny of mass limits the sensors and computers you can afford to fly; the unforgiving environment guarantees the disturbances and the radiation; and the beauty of the feedback loop is the only thing standing between a mission and a crater.

💡 Intuition: autonomy is just the loop, run where the action is. There is nothing exotic in an "autonomous" spacecraft beyond the very loop of §27.1 — sense, estimate, decide, actuate — physically located onboard instead of split with the ground. A self-driving car, a cruise missile, a drone holding position in wind, and a Mars lander are the same three boxes; what differs is only where the boxes run and how much they must handle alone. The light-time arithmetic simply decides how much of the loop you are permitted to keep on Earth. Past a few light-seconds, the answer is: almost none.

🔄 Check Your Understanding 1. State the inequality that makes a Mars landing necessarily autonomous, using rough numbers. 2. Why can a LEO satellite keep the ground "in the loop" for maneuver planning while a Mars lander cannot, for descent? 3. Name two properties an onboard flight computer must have because the loop is autonomous, and say why each is forced by autonomy.

Answers

1. Time-to-land ($\approx 7\ \text{min}$) is much less than the one-way light-time to Earth ($\approx 14\ \text{min}$ at a typical Mars distance), so a round trip ($\approx 28\ \text{min}$) is far longer than the whole descent — Earth cannot react in time, so the vehicle must decide onboard. 2. LEO round-trip light-time is under a second, short enough for ground commands on the slow (maneuver-planning) timescale; Mars descent happens in minutes while the one-way light-time is many minutes, so no ground command can arrive within the descent at all. 3. It must be radiation-hardened (no crashes in the particle environment, since no one can reboot it in time) and highly reliable/redundant (no second chance during the autonomous critical phase) — both forced because there is no timely human intervention when the loop runs alone.

Mission Design Checkpoint: your GN&C approach note (and an illustrative PID helper)

This chapter adds a GN&C approach note to your Mission Design Review — the paragraph that says how your spacecraft will know where it is, decide where to go, steer there, and how much of that it must do alone. It draws directly on the pointing requirement you set in Chapter 14 and the tracking-and- navigation note from Chapter 13, and it feeds the synthesis in Chapter 29.

The design note. For your track, write four short lines:

• Navigation — the sensor suite and estimator. Track A (GEO comsat): star trackers + sun sensors + gyros for attitude; ground ranging/Doppler and (in GTO) GNSS for orbit; an EKF fusing them. Track B (lunar lander): add a landing radar/altimeter and terrain-relative camera for the descent. Track C (Mars orbiter): DSN radiometric tracking + optical navigation. Track D (asteroid rendezvous): optical navigation against the target body, the dominant sensor near a small body.
• Guidance — the targeting method. Ascent PEG (if you specify your own launch), Lambert/velocity-to-be- gained targeting for orbit-insertion and rendezvous burns, or closed-loop descent guidance for a landing.
• Control — three-axis stabilization with the actuators you chose in Chapter 14 (reaction wheels + thrusters/magnetorquers for dumping; a gimbaled engine for burns), driven by a PID (or similar) law; cite your pointing-accuracy requirement.
• Autonomy — the required level, argued from light-time. A LEO/GEO mission can be ground-supervised for planning but must self-control attitude; a Mars or asteroid mission must navigate and safe itself, and land or arrive fully autonomously.

The code. Add an illustrative PID controller helper. Like the scalar kalman_update of Chapter 13, this is a teaching aid, not a canonical astrotools module (GN&C is not in the package schedule) — but it composes with that filter to sketch a full navigate-then-control loop. It reproduces the hand-trace of §27.4 (proportional-only, so its steady state is the $2^{\circ}$ droop):

class PID:
    """Illustrative discrete PID controller (teaching aid, not a canonical astrotools module)."""
    def __init__(self, kp, ki, kd, dt):
        self.kp, self.ki, self.kd, self.dt = kp, ki, kd, dt
        self.integral, self.prev_error = 0.0, 0.0

    def step(self, error):
        self.integral += error * self.dt
        derivative = (error - self.prev_error) / self.dt
        self.prev_error = error
        return self.kp * error + self.ki * self.integral + self.kd * derivative

# Reproduce the proportional-only pointing trace of Section 27.4 (Ki = Kd = 0):
ctrl = PID(kp=0.5, ki=0.0, kd=0.0, dt=1.0)
theta, w = 0.0, 1.0                      # start on target; +1 deg/s disturbance
history = []
for _ in range(5):
    u = ctrl.step(-theta)                # error = setpoint(0) - theta
    theta = theta + (u + w) * ctrl.dt    # angle updates by command + disturbance
    history.append(round(theta, 4))
print(history)
# Expected output:
# [1.0, 1.5, 1.75, 1.875, 1.9375]

The angle marches toward the $2^{\circ}$ droop we derived by hand — proof the code and the arithmetic agree. Setting ki=0.5 would drive that droop to zero, as the second trace showed. In the capstone (Chapter 40) this note becomes the GN&C section of your finished MDR: the loop that would actually fly the mission you have designed.

Summary

Guidance, navigation, and control is the closed loop that flies every vehicle. Carry these forward:

Key equations and numbers: scalar Kalman gain $K = \sigma_{\text{pred}}^2/(\sigma_{\text{pred}}^2 + \sigma_{\text{meas}}^2)$ (defined in Ch. 13); PID law $u = K_p e + K_i!\int e\,dt + K_d\,\dot e$; control torque from a gimbal $M_c = F\sin\delta\,L$; light-time $t = D/c$ with $c \approx 3.0\times10^{5}\ \text{km/s}$ (Mars one-way $\approx 4$–$24\ \text{min}$).

Spaced Review

Retrieval strengthens memory. Answer from memory first, then check, then look back at the cited chapter.

1. (Ch. 13) In the Kalman filter, what happens to the estimate's uncertainty in the predict step, and in the update step? Why can the fused uncertainty be smaller than both the prediction's and the measurement's?
2. (Ch. 13) A navigation filter predicts a position with variance $\sigma_{\text{pred}}^2 = 16$ and then gets a measurement with variance $\sigma_{\text{meas}}^2 = 4$. What is the Kalman gain $K$, and does the update lean toward the prediction or the measurement?
3. (Ch. 14) Why is a single Sun-direction measurement not enough to determine a spacecraft's full three-axis attitude, and what is the minimum that suffices?
4. (Ch. 14) A control loop holds attitude with reaction wheels against a steady disturbance torque. Why must the vehicle also carry thrusters or magnetorquers, no matter how good the wheels are?
5. (Ch. 13 & 14) GN&C fuses a fast-but-drifting sensor with a slow-but-absolute one. Name the pair used for attitude and the algorithm that blends them.

Answers

1. The uncertainty grows in the predict step (extrapolating on the model adds process noise) and shrinks in the update step (a measurement adds information). The fused uncertainty can beat both inputs because variances add in inverse: $1/\sigma_+^2 = 1/\sigma_{\text{pred}}^2 + 1/\sigma_{\text{meas}}^2$, so combining two independent estimates is strictly sharper than either. 2. $K = 16/(16+4) = 0.8$; the gain is closer to 1, so the update leans toward the (sharper) measurement, moving the estimate $80\%$ of the way from prediction to measurement. 3. One Sun vector fixes only the two degrees of freedom orienting the body relative to the Sun line; you can still rotate freely about that line. You need a second, non-parallel reference direction (a star or the magnetic field) — or one full-attitude sensor like a star tracker. 4. Reaction wheels are internal actuators: absorbing a steady one-directional disturbance spins them ever faster until they saturate. Only an external torque (thrusters, magnetorquers) can remove the accumulated momentum — momentum dumping — because $\dot{\mathbf{H}}_{\text{total}} = \mathbf{M}_{\text{external}}$. 5. A drifting rate gyroscope paired with an absolute star tracker, blended by the Kalman filter.

What's Next

We have now given the spacecraft a nervous system: it can sense its state, decide where to go, steer there, and — when Earth is too far to help — do all of it alone. Every subsystem of Part IV so far has kept the machine alive in the unforgiving environment: structure against loads, thermal control against the temperature extremes, power to run the electronics, communications to reach home, and now GN&C to fly the vehicle. But the moment we put people aboard, the environment acquires a new and far less forgiving target. A satellite tolerates a wide temperature band and needs no air; a human tolerates almost none of what space offers and dies within minutes of losing any of a short list of essentials. In Chapter 28 we turn to the hardest customer in spaceflight — the human body — and to the closed-loop system that keeps it alive: environmental control and life support. The control loops do not go away; they simply acquire the highest-stakes setpoint of all, a breathable atmosphere around a fragile crew.