How the program is run

Program

TrueGrade runs on the systems-engineering framework taught in the AERO 388 sequence: leveled requirements, a verification matrix, written trade studies, deliberate fault injection, and gated design reviews — the same discipline used on real aerospace programs. This page is the record of that process, not a description of it.

The largest technical risk, stated first

The v1 target is ≤10 mm horizontal RMSE. It is aggressive for aerial mapping, and it is unverified. Whether the chosen LiDAR and RTK/PPK correction chain can actually reach it will be confirmed — or the target revised — at System Requirements Review, against real data rather than a specification sheet. We are testing this early rather than assuming it.

≤10 mm

Horizontal RMSE target

Target — SRR — pending

Leveled, traceable requirements

Every requirement starts from a stakeholder need and cascades down through system, subsystem, component, and interface levels. Each one is written in verifiable shall-language and traces back to the need that justifies it — nothing is a requirement because it sounded right.

  • L0Stakeholder need
  • L1System requirement
  • L2Subsystem requirement
  • L3Component requirement
  • L4Interface requirement
40

Traceable requirements drafted (L0–L4, approximate)

Baseline drafted

Verified and validated, not asserted

A Verification Cross-Reference Matrix maps every requirement to at least one verification task and one validation task. Each is closed by one of four methods:

Inspection
Visual or dimensional check against the requirement.
Analysis
Calculation, model, or simulation.
Demonstration
A qualitative operational check, not instrumented data.
Test
Quantitative data collected under controlled, repeatable conditions.

Trade studies, not asserted answers

Every major design choice is decided by a written, weighted trade study, not a single asserted answer. Some are closed; most are still open, because the build hasn't started.

DecisionStatusBasis
Flight autopilot: PX4 vs. ArduPilotOpenTo be selected by trade study before PDR.
LiDAR sensor class: standard near-infrared vs. bathymetric (green-wavelength)OpenWater-penetration use cases (bridge, dam) need to see through shallow water; standard near-infrared LiDAR cannot.
Positioning strategy: RTK vs. PPKDrafted — recommends bothRTK for real-time flight guidance and geotagging; PPK-first for the delivered georeferencing, so a dropped live link never costs the accuracy result.
Flight controller: buy vs. buildDecided — build, with fallbackThe open-standard Pixhawk 6C stays the baseline and schedule fallback while an in-house board is developed, so flight testing is never blocked on custom-board bring-up.
Photogrammetry / point-cloud pipelineOpenOpenDroneMap and related open-source tooling under evaluation.

Fault management (FDIR)

A Fault Response Matrix enumerates every failure mode the team can identify. Each one is deliberately injected and observed — not assumed away — to confirm the system detects it, isolates it, classifies it correctly, and responds the way the matrix says it should.

FaultDesigned response
Loss of GNSS/RTK correction linkAutomated fail-safe: return-to-launch or controlled landing.
Geofence breachEnforced fail-safe response, independent of operator action.
Low battery / voltage anomalyPower module triggers a defined low-battery response.
Telemetry (SiK) link lostOverride and kill authority remain on a separate-frequency ExpressLRS link — one link failure never removes both mission control and override.
Any condition, any timeHardware E-stop, independent of software, always available to the operator.

Program gates

Progress is gated by review, not by calendar. Each gate has explicit, data-backed entry and exit criteria, and the project does not advance with open action items.

  1. 01

    SRRSystem Requirements ReviewFall 2026

    Requirements baselined; numeric targets locked; every requirement verifiable.

  2. 02

    PDRPreliminary Design ReviewWinter 2026–27

    Design mature; error budget predicts the accuracy number; trade studies closed.

  3. 03

    CDRCritical Design ReviewWinter/Spring 2027

    Detailed design complete; every requirement traced to a specific test event.

  4. 04

    TRRTest Readiness ReviewSpring 2027

    Test articles and SOPs ready; safety tests approved; test-site airspace authorized.

  5. 05

    FRRFlight Readiness ReviewApril 2027

    System built and subsystem V&V closed; v1 flight and accuracy-validation campaign begins.

Test escalation

Every behavior is proven in simulation, then on the bench and in hardware-in-the-loop testing, then in tethered flight — before it is ever tried in full flight. No fault is exercised in the air for the first time.

  1. Simulation
  2. Bench / hardware-in-the-loop
  3. Tethered flight
  4. Full flight

Powered and flight tests additionally require an approved test procedure and faculty-advisor / EHS sign-off before execution.