← All technology pathways
FROM A MISSION TO A TESTABLE MODEL

UAVs & autonomous systems

Explore flight, sensing and control through a fictional survey mission, an energy estimate and a tested state machine.

Build it. Try it. Change one thing.What would you test when the easy example works?Illustrated learning characters · fictional scene
STARTER MATERIAL / FICTIONAL SCENARIO

Make a first version.

The Builder and Researcher compare ways to inspect fictional greenhouse roofs.
Paper-map sites: A(0,0), B(2,0), C(2,2), return A; units are abstract.
Nominal energy = 60 Wh; reserve fraction = 0.20
Energy allocated to the modelled mission = 60 x 0.80 = 48 Wh
Assumed average power = 180 W
Modelled time = 48 / 180 x 60 = 16 minutes
Illustrative classroom states: READY, OBSERVE, REVIEW_REQUIRED
If data is missing or a model limit is breached: mark REVIEW_REQUIRED.
These values and states are not flight settings or a real emergency procedure.

Copy this into your chosen tool or trace it on paper. Do not enter passwords, private learner data or API keys.

STAGE 1 / 6

Start with the mission, not the aircraft

A UAV system combines an aircraft, power, sensing, communications, control and an operator. An aerial viewpoint is useful only when it solves the actual information problem.

Build & try

The Researcher needs to count visible roof panels on a fictional site. Compare a UAV, existing public imagery and a ground inspection. Define resolution, access, time and privacy needs. Use an invented map and no identifiable people.

Show that it works

Your brief includes a simpler alternative and a reason to choose or reject aerial inspection.

STAGE 2 / 6

Explain flight and system trade-offs

Forces have direction. Fixed-wing flight and a hovering multirotor balance forces differently; a single sketch cannot describe every manoeuvre. Sensors estimate quantities, while controllers use estimates to change behaviour.

Build & try

Draw separate simplified diagrams for an airplane in steady level flight and a multirotor in a still-air hover. Label weight and the opposing aerodynamic force or total rotor thrust. Add sensors, controller, communication and operator to a system diagram.

Show that it works

You distinguish a force balance from an explanation of how lift is produced, and identify an assumption such as constant speed or no wind.

STAGE 3 / 6

Estimate an energy budget

Available energy divided by average power gives an idealised duration. Actual use changes with payload, wind, manoeuvres, battery condition and temperature. A reserve in a worksheet is not an approved operating limit.

Build & try

Reproduce the 16-minute starter result. Recalculate at 240 W: 12 minutes. Compare a fictional 11-minute task under both estimates and explain why the smaller margin requires investigation. Keep Wh, W, hours and minutes separate.

Show that it works

Your calculation retains the reserve and labels its assumptions. You do not present modelled minutes as guaranteed endurance.

STAGE 4 / 6

Make uncertainty visible

A sensor reading and the true quantity can differ. Missing position or battery data should not appear as a healthy system. Mapping work also needs a way to verify whether the data answers the original question.

Build & try

On the abstract map, represent each point as a region of uncertainty rather than an exact dot. Create sample readings with a missing position, stale timestamp and conflicting energy estimate. Record what cannot be concluded from each.

Show that it works

Your evidence distinguishes absent, stale and contradictory data. The simulation does not claim centimetre accuracy or a successful survey from an unverified reading.

STAGE 5 / 6

Test a classroom state machine

A state diagram names allowed transitions and the conditions that trigger them. Explicit fault cases are more informative than a demonstration that only works with perfect inputs.

Build & try

Trace READY to OBSERVE only when the fictional checks pass. For missing data or a model budget breach, record REVIEW_REQUIRED and a reason. Test normal inputs, missing data, conflicting readings and restart. This paper/code model must not be connected to a flight controller.

Show that it works

Every test has an expected state and observed result. Restart resets the model. You document that real emergency actions depend on the aircraft, environment and approved procedures.

STAGE 6 / 6

Defend a mission recommendation

A useful feasibility report can recommend against using a drone. The value lies in the evidence and the decision, not in choosing the most complex technology.

Build & try

Submit the mission brief, alternatives, force/system sketches, energy cases and state tests. State what a qualified operator would need to verify before any real operation, including local aviation requirements, permissions and conditions. Use simulations for the complete pathway.

Show that it works

A reviewer can reproduce your model and explain its limits. Your work makes no claim of pilot qualification, operational approval or validated airworthiness.

A DIFFERENT WAY TO TRY IT

Make the idea your own.

Choose a twist. Use paper, a sketch or a conversation.

Optional practice. Copy useful observations into your workbook; choosing a twist does not record completion.

Compare ideas with someone you know. Sharing is optional.