UAV Systems Engineering · Capstone 4 of 4

Complete GNSS-Denied Autonomous UAV

The systems-engineering capstone: not “does the algorithm work” but “can you show, with evidence, that the whole vehicle meets its requirements, including when parts fail.”

Builds on modules 1, 2, 3, 4, 5, 6, 7, 8
About 60–100 hours; individual or team
Implementation-specific

This project is graded on engineering judgement as much as on running code. You will specify, design, budget, integrate and verify a GNSS-denied UAV, produce the ten documents that a real programme would require, and defend the trade-offs in them.

Mission and scope

Design a UAV for inspection of an industrial site with indoor and outdoor segments: it must fly a 10-minute mission, navigate where GNSS is unavailable or untrusted, map its surroundings, avoid obstacles, respond safely to the failure of any single navigation sensor, and finish with a controlled landing. The vehicle carries a stereo camera, an IMU, a 3D LiDAR, a GNSS receiver, an NVIDIA Jetson-class companion computer, and a PX4 flight controller.

Fix the mission, environment, payload and operational limits in the first document and treat them as requirements. You are encouraged to adapt the scenario (tunnel, warehouse, forest) but must state what changes.

Reference architecture for the final capstone. You must justify every block and interface you keep, add or remove.

What you will implement

Requirements and architecture: derive verifiable requirements and decompose them (lessons M8-T1, M8-T2).
Sensor selection with a trade study, calibration plan and timing design (lessons M7-T8 to M7-T16).
Sensor fusion and state estimation with VIO, LIO and GNSS, honest covariance and consistency monitoring (modules 3 and 4).
Localisation, mapping and obstacle perception sufficient for the mission (module 4).
Motion planning and flight control: trajectory generation and tracking with PX4 offboard control (modules 5 and 6).
Fault detection and degraded navigation: confidence levels, modes and failsafes with timers derived from drift (lessons M2-T16, M8-T9 to M8-T14).
System verification: simulation, hardware-in-the-loop where available, ground tests and a flight-test acceptance plan (lessons M8-T3 to M8-T6).

System architecture

The reference architecture above is a starting point. Whatever you build, your architecture document must show: every interface with its message type, rate, frame and owner (the ICD); which computer runs each function and its compute and power share; what happens when each sensor, the companion computer, or the link fails; and where timing and synchronisation are established.

Layers of the final architecture and the lessons that support them
Layer	Minimum content	Where to look
Sensors	Models or classes, mounting, field of view, rates, power	M1-T8, M1-T10, M7-T12 to M7-T14
Perception and odometry	VIO and LIO, health indicators, covariance	M2-T10 to M2-T14, M4-T4, M4-T8
Estimation	Fusion estimator, gating, consistency	M3-T4 to M3-T16
Planning and control	Trajectory, tracker, constraints	M5-T8 to M5-T15
Flight software	PX4, EKF2 external odometry, offboard	M6-T5, M6-T10, M6-T11
Safety	FMEA, FDIR, degraded modes, failsafes	M8-T7 to M8-T14

Requirements

Capstone requirements and how each is verified
ID	Requirement	Verification method
SYS-01	The vehicle shall complete a 10-minute mission over a 300 m route with GNSS unavailable for the middle 60% of the route.	Flight test or simulation of the full route (VT-01)
SYS-02	Horizontal position error at the end of the GNSS-denied segment shall not exceed 1.0 m (95th percentile over runs).	Test with ground truth; evo analysis (VT-02)
SYS-03	The vehicle shall maintain at least 1.0 m clearance from obstacles larger than 0.2 m at speeds up to 2 m/s.	Simulation and ground test with obstacles (VT-03)
SYS-04	Loss of any single navigation sensor (GNSS, camera, LiDAR) shall not cause loss of control; the vehicle shall continue in a defined degraded mode.	Fault-injection in simulation and ground/flight test (VT-04)
SYS-05	GNSS spoofing with a position ramp of at least 1 m/s shall be detected within 10 s and GNSS excluded.	Replay-injection test (VT-05)
SYS-06	On loss of all odometry aiding, the vehicle shall execute a controlled stop within $T_{\max}$ seconds, derived from the drift rate and the clearance (lesson M8-T11).	Test and analysis (VT-06)
SYS-07	End-to-end latency from sensor exposure to setpoint shall not exceed 100 ms (p99).	Timing measurement (VT-07)
SYS-08	Companion computer power, thermal and compute shall stay within the budget at maximum ambient temperature.	Bench test under load (VT-08)
SYS-09	Loss of the GCS link for 5 s shall trigger the configured link-loss action.	Ground and flight test (VT-09)
SYS-10	The estimator shall be statistically consistent: mean NIS within the 95% interval for each fused source in nominal conditions.	Log analysis (VT-10)

The ten deliverables: what each must contain

The ten deliverables and what each must contain
#	Deliverable	Must contain	Evidence of quality
1	System requirements document	Mission, environment, operating limits, numbered verifiable requirements with rationale; assumptions; out-of-scope items	Every requirement is testable and has a verification method; derived requirements trace to parents
2	System architecture diagram	Blocks, interfaces, frames, rates, compute allocation, power domains, failure containment	A reviewer can find, for every failure mode, where it is detected and handled
3	Sensor selection and trade study	Candidate sensors, criteria with weights, vendor-published specifications with sources, sensitivity analysis of the ranking	Specifications are cited, not invented; choice survives changing the weights
4	Interface Control Document	For each interface: producer, consumer, message type, rate, frame, units, timing (stamp semantics), latency budget, failure behaviour, version	Two engineers could implement both sides independently from the ICD alone
5	Sensor calibration plan	Intrinsics, camera-IMU and LiDAR-IMU extrinsics, time offsets, IMU noise (Allan), procedures, tolerances, frequency and re-calibration triggers	Each parameter has an acceptance tolerance and a check that can be run in the field
6	Timing and synchronisation plan	Clock sources, trigger scheme, timestamp semantics, PTP/PPS usage, jitter budget, monitoring of offsets	Measured offsets and jitter against the budget
7	Compute, power and thermal budget	Per-function CPU/GPU/memory use, power per mode, thermal limits at ambient maximum, margins	Measurements on the target computer under the full pipeline
8	FMEA	Navigation, compute, power, link, actuators; severity-first prioritisation; detection and mitigation per mode	Every severity ≥ 9 mode has a verified mitigation (lesson M8-T7)
9	Integration test plan	Test levels (unit, SIL, HIL, ground, flight), test cases per requirement, pass/fail criteria, environment, tools	Requirements-to-tests traceability matrix with no gaps
10	Flight-test acceptance report	Test conditions, results against each requirement, deviations, anomalies, residual risks, operating limitations	States what was not verified and the resulting limits on operation

Interface Control Document: starter table

Extend this table for every interface in your architecture. The fields shown are the minimum.

Starter ICD (fill every “to be budgeted” from your measurements)
ID	From → to	Message / medium	Rate	Frame · units	Timestamp semantics	Latency budget	On failure
IF-01	IMU → fusion	sensor_msgs/Imu	IMU-dependent (set from datasheet)	FLU · rad/s, $m/s^{2}$	Acquisition time on the shared clock	To be budgeted	Estimator coasts; health flag
IF-02	Camera → VIO	sensor_msgs/Image + CameraInfo	From camera mode	Optical frame · pixels	Exposure start or trigger time	To be budgeted	VIO reports lost; monitor lowers confidence
IF-03	LiDAR → LIO	sensor_msgs/PointCloud2 with per-point time	From LiDAR mode	LiDAR frame · $m$	Per-point time relative to scan start	To be budgeted	LIO reports lost
IF-04	Fusion → PX4 EKF2	px4_msgs/VehicleOdometry on /fmu/in/vehicle_visual_odometry	Fixed by design	NED/FRD · $m$ , m/s	timestamp_sample = acquisition time	To be budgeted	EKF2 falls back per its parameters
IF-05	Planner → PX4	OffboardControlMode + TrajectorySetpoint	Fixed, above PX4’s minimum	NED · $m$ , m/s	Publication time	To be budgeted	PX4 leaves offboard mode
IF-06	Fusion → supervisor	Navigation state + health record (custom)	Estimator rate	Any · documented	Estimator time	To be budgeted	Supervisor assumes RED

Verification strategy

Unit and component tests: frame conversions, monitors, state machines (as in the lessons’ runnable examples).
Software-in-the-loop: the full stack with PX4 SITL and a simulated environment; every failure of the FMEA injected at least once (lesson M8-T4); use the GNSS-Denied Failure Simulator to design the scenarios first.
Hardware-in-the-loop and bench: the real companion computer and flight controller with replayed or simulated sensors; timing, power and thermal budgets measured here.
Ground tests: props off, then tethered: sensor health, calibrations, failsafe triggers, link-loss behaviour.
Flight tests: staged from benign to demanding, each with entry criteria, a safety pilot, abort criteria and a written result (lesson M8-T5). Where flight is not possible for you, perform the equivalent in simulation and say so in the acceptance report.

Every requirement in the table above must appear in the traceability matrix with at least one test and the result of that test.

Suggested schedule

A six-phase schedule
Phase	Content	Output
1	Mission, requirements, architecture, FMEA first pass	Documents 1, 2, 8 (draft)
2	Sensor trade study, calibration and timing design	Documents 3, 5, 6
3	Estimator and perception in simulation or on datasets	Evaluation reports
4	Planner, controller and PX4 integration, ICD	Document 4, closed-loop SIL runs
5	Budgets measured, failure injection, degraded modes	Document 7, FMEA update
6	Integration test plan executed; acceptance report	Documents 9 and 10

Deliverables

1. System requirements document.
2. System architecture diagram.
3. Sensor selection and trade study.
4. Interface Control Document.
5. Sensor calibration plan.
6. Timing and synchronisation plan.
7. Compute, power and thermal budget.
8. Failure Mode and Effects Analysis.
9. Integration test plan.
10. Flight-test acceptance report.

Acceptance criteria and grading rubric

Acceptance criteria
Criterion	Acceptable	Strong
Requirements	Numbered, verifiable, with verification methods	Derived requirements traced to parents; rationale for each limit
Architecture and ICD	Complete interfaces with rate, frame and failure behaviour	Implementable independently from the ICD; latency budget closed
Trade study	Cited sensor specifications and a weighted comparison	Sensitivity analysis; rejected options explained
Calibration and timing	Plans with tolerances	Measured offsets and residual error budgets
Budgets	Compute, power, thermal numbers from measurements	Margins at worst-case ambient with worst-case mode
FMEA and FDIR	Severity-first, each high-risk mode mitigated	Mitigations verified by fault injection with detection times
Verification	Traceability matrix without gaps	Results with statistics over repeated runs and honest limitations
Acceptance report	Requirement-by-requirement result	Operational limitations derived from what was not verified

Common failure points

Choosing sensors from marketing numbers; cite vendor documentation and state test conditions.
Writing requirements that cannot be verified (“robust”, “reliable”) instead of measurable limits.
An architecture diagram that omits power, time and failure paths.
Budgets from datasheet peaks instead of measured load of the full pipeline.
An FMEA written once at the end instead of driving the design.
Claiming success from the nominal case; the failure cases are the capstone.
Reporting only means: report percentiles and worst cases (lesson M7-T6).

References

Record your progress

Capstones are assessed by you against the rubric above, so this records your own sign-off.