Designing GNC & Autonomy Systems

When asked to design or troubleshoot a flight/vehicle intelligence stack, immediately frame the problem in the three-layer GNC hierarchy plus autonomy on top:

Autonomy (decision-making: mission planning, obstacle avoidance, task allocation)
   ↑ commands / constraints down, state up
Guidance (where should I go? trajectory & command generation)
   ↑
Navigation (where am I? state estimation)
   ↑
Control (how do I get my actuators to obey? stabilization)
   ↑
Physical Plant (airframe, motors, control surfaces)

Immediately identify, for the system in question:

1. What needs to be controlled (which DOF, what actuators, what disturbance rejection is needed)
2. What needs to be known (which states, what sensors are available, what's the GPS-denied risk)
3. What needs to be decided (trajectory constraints, mission objectives, real-time replanning needs)
4. What sits above it all (autonomy: perception-to-decision loop, human-on/in-the-loop requirements)

Progress:

• Step 1: Define the platform & mission envelope (DOF, dynamics class, environment — GPS-available vs. GPS-denied, indoor/outdoor, contested vs. benign)
• Step 2: Design the Navigation layer (sensor suite + fusion algorithm)
• Step 3: Design the Control layer (control law matched to dynamics complexity & fault tolerance needs)
• Step 4: Design the Guidance layer (trajectory generation matched to constraints)
• Step 5: Define the Autonomy layer (decision logic, mission-level behavior, failure/degradation modes)
• Step 6: Verify layer interfaces (units, rates, latency budgets, failure propagation)
• Step 7: Specify test/validation plan (SIL → HIL → bench → flight test)

Step 2 detail — Navigation layer selection

Match sensor/algorithm to the drift-vs-availability tradeoff:

• GNSS available & benign → GPS/INS loosely-coupled Kalman Filter is sufficient default.
• GNSS denied/degraded (indoor, contested, urban canyon) → add Visual Odometry/SLAM, tightly-coupled EKF/UKF fusion, consider VIO (visual-inertial odometry).
• Long-duration missions → prioritize drift correction (map-matching, beacons, periodic GPS fixes) since pure INS integrates error unboundedly.
• Always state explicitly: what drifts, how fast, and what corrects it.

Step 3 detail — Control layer selection

Default to the simplest law that meets requirements; escalate only when justified:

• Single-loop, weakly-coupled axes, well-known dynamics → PID (cascaded loops: rate → attitude → position).
• Strongly coupled multi-axis dynamics (MIMO), need formal stability guarantees → State-Space control (LQR, pole placement) with a linearized model at trim points.
• Dynamics can change unpredictably (actuator/surface damage, payload/CG shift, extreme wind) → Adaptive control (MRAC, gain-scheduling, or online parameter estimation) layered on top of a baseline controller, never as the sole safety net.
• Always specify: bandwidth requirements, actuator saturation limits, and a fallback/degraded-mode controller.

Step 4 detail — Guidance layer selection

• Static, known environment → offline trajectory optimization (minimum-snap, splines) respecting aerodynamic/structural limits.
• Dynamic/uncertain environment → real-time replanning (RRT*, MPC-based guidance, potential fields) with a hard real-time budget matched to vehicle speed and obstacle density.
• Always couple guidance output units/rate to what the control layer's inner loop expects (e.g., guidance emits waypoints/velocity commands at 10 Hz, control consumes attitude commands at 250+ Hz).

Step 5 detail — Autonomy layer

• Define the perception → decision → action loop explicitly.
• Specify degradation behavior: what happens on sensor loss, comms loss, guidance infeasibility (e.g., loiter, RTL, safe-landing state machine).
• Note collaboration boundary with CS/perception teams (SLAM, object detection) — GNC consumes their state estimates/detections as inputs, doesn't own perception algorithms itself.