System Analysis
Turning requirements into a design that closes — and survives the off-nominal cases. This section works end-to-end system studies: budgets, actuator/sensor sizing, control-law and estimator selection, stability and jitter, and adversarial "what-if" reviews. The recurring lesson: a design that closes at nominal is necessary but not sufficient; margin is the currency you spend on the cases that actually break programs.
Symbols used on this page are defined in the Nomenclature → notation conventions.
Three studies, a six-part implementation tutorial that takes the perception study from paper design into a production ROS 2 system, and a process tutorial on requirements traceability.
Process & rigour
A design that closes is necessary but not sufficient: on a safety-critical vehicle you must also be able to demonstrate that every behaviour was asked for, implemented and tested. That is a mechanical problem, and it has a mechanical solution.
Case studies
ADCS — laser-comm pointing
A full attitude-determination-and-control design for a laser-comm platform: requirements → disturbance budget → CMG sizing → sensors → control laws → MEKF → jitter budget → FDIR, plus a red-team critique.
Rocket navigation
A launch vehicle's navigator as a sequence of estimators: coarse and fine alignment, what gyrocompassing can and cannot observe, the GNSS-INS error-state EKF, free-inertial coast, in-flight realignment, orbit propagation, and relative nav to a moving deck — with the mode state machine and the ICD fields that cause flight anomalies when left implicit.
Perception stack
The same treatment applied to an autonomous-driving suite: 6 cameras + LiDAR + radar → a shared BEV representation → dense occupancy → multi-object tracking, with the latency budget, failure taxonomy and real nuScenes results that decide whether the design closes.
Implementation tutorial — perception in production (ROS 2)
A design that closes on paper still has to run on a vehicle, on a deadline, on real middleware. These six pages take the perception study the rest of the way: what the nodes are, what happens between two callbacks, how the metrics are actually computed, how the model gets ported, what hardware it needs, and where the whole thing would hurt.
1 · Architecture & message contracts
Nodes, topics, deadlines and the data flow from sensor driver to track.
2 · QoS, execution & zero copy
Executors, callback groups, shared memory, and QoS as a safety choice.
3 · mAP · recall · MOTA
The metric mathematics, and what each number hides.
4 · BEVFusion port & testing
Getting the model into the graph, then proving it still works.
5 · Model size, FPS & GPUs
What fits in the compute budget, measured rather than hoped.
6 · Design critique & what-ifs
The adversarial review: where this architecture breaks first.
The method
disturbance budget
sensor sizing
estimator
error budget
what-if margins
A second-order closed loop underlies most pointing/settle behaviour — damping ratio $\zeta$ sets overshoot, natural frequency $\omega_n$ sets speed. Get intuition here, then see it applied in the ADCS jitter budget: