Appendix B — Appendix B: Lab Assignments

The four lab assignments collected here are the hands-on counterparts to the book’s chapters. Every Related Lab line in the body of the book points to one of the sections below. Each lab is presented in a common format: a project overview, the learning outcomes it targets, the concrete technical requirements, graduate-level extension expectations where they exist, and — for completeness — the point breakdown under which the lab was originally scored. The grading tables are historical reference material from the labs’ origin; they are included so a reader can see how effort was weighted, not because this book imposes any grading structure of its own.

The labs form a deliberate progression: build and fly real hardware, move to simulation and safety envelopes, add onboard perception, and finally close the loop with autonomous decision-making. A reader working through the book can attempt them in order, at either the baseline or the graduate-extension depth. Where an original lab specified a submission mechanism, that detail has been generalized: submit per your instructor’s current guidance, or simply keep the artifacts (videos, logs, reflections) as your own record of the work.

B.1 Collaborative Drone Build & Flight Demonstration

This lab applies the material of Part I — multirotor anatomy, materials and power, sensing, and companion computers.

B.1.1 Project Overview

Teams assemble a functional drone from a provided kit, demonstrate controlled flight for a minimum of 10 seconds, and reflect individually on their contributions. The lab is deliberately hardware-first: before any autonomy is written, every participant should have handled a frame, a motor, an electronic speed controller, and a flight controller, and should have debugged at least one thing that refused to work.

B.1.2 Learning Outcomes

Develop hands-on experience with hardware assembly and systems integration.
Practice teamwork, communication, and project coordination.
Demonstrate problem-solving and troubleshooting skills.
Reflect on individual contributions within a collaborative engineering task.
(Graduate-level extension) Exhibit leadership, mentorship, and advanced technical contribution.

B.1.3 Project Requirements

Team coordination. Coordinate outside scheduled session time as needed to complete the build. Exchange contact information or set up a shared communication channel early.
Drone assembly. Assemble the kit completely and correctly: frame, motors, propellers, wiring, and flight controller all installed properly. The team is responsible for troubleshooting the vehicle to a flight-ready state.
Flight demonstration (team requirement). At least 10 seconds of continuous, controlled flight — stable, intentional, and safely executed. Documentation: a video recording clearly showing takeoff, sustained flight of 10 seconds or more, and landing or a controlled end to the flight.
Individual reflection (one page maximum). Describe your specific contributions, the challenges you encountered and how you addressed them, what you learned, and how the team’s communication worked in practice.

B.1.4 Graduate Student Expectations

Graduate participants are expected to take on leadership roles within the team, guide and mentor less experienced teammates, contribute beyond baseline expectations (technically or organizationally), and help ensure project completion and team coordination.

B.1.5 How This Lab Was Originally Scored

The original point breakdown (100 points total) is reproduced for reference:

Component	Points	Criteria
Drone assembly quality (team)	20	Correct, complete, functional assembly
Flight performance (team)	25	At least 10 s of stable, controlled flight
Video documentation (team)	15	Clear, complete, meets requirements
Team coordination (team)	10	Evidence of collaboration and organization
Contribution quality (individual)	15	Meaningful, specific individual work
Reflection quality (individual)	10	Thoughtful, concrete reflection
Professionalism (individual)	5	Clarity, formatting, one-page limit

A graduate-level adjustment of up to ±10 points applied, based on leadership, mentorship, and level of contribution relative to expectations.

B.1.6 Practical Notes

Safety first: fly only in approved areas and keep safe distances from people and objects. If the aircraft crashes, do not grab it — let it crash (a tether, if available, is the safer containment). Start early; hardware issues take time to debug. Assign roles (builder, tester, coordinator, documenter), test incrementally before attempting the full flight, and communicate frequently.

B.2 Software-in-the-Loop (SITL) Simulation & Geofencing

This lab applies the material of Part II — closed-loop control, the PX4 autopilot stack, mission scripting, and geofencing and failsafes.

B.2.1 Project Overview

Building on the hardware foundations of the first lab, this lab shifts to simulation-based autonomy and safety protocols. Teams configure a software-in-the-loop (SITL) environment using Gazebo and QGroundControl (QGC), then simulate a series of waypoint commands constrained by an active, automated geofence. The point is not merely to make a simulated vehicle move, but to watch a safety envelope do its job: the mission must include a deliberate encounter between the vehicle and the fence.

B.2.2 Learning Outcomes

Develop proficiency with SITL environments (Gazebo and QGC).
Practice mission planning and waypoint navigation.
Implement safety protocols through geofencing configurations.
Demonstrate collaborative project management in a simulated environment.
(Graduate-level extension) Provide advanced technical troubleshooting and leadership in simulation architecture.

B.2.3 Project Requirements

Simulation setup. Configure Gazebo and QGroundControl to communicate via SITL. Teams coordinate outside scheduled session time to finalize simulation parameters.
Mission implementation. Define and execute a flight path with at least four distinct waypoints. Implement an active geofence in QGC that triggers a failsafe — for example, return-to-launch (RTL) — if the simulated aircraft breaches the defined perimeter.
Demonstration. The simulation must show the drone successfully traversing the waypoints and responding appropriately to the geofence constraints. Documentation: a screen recording clearly showing the QGC mission plan, the drone’s movement in Gazebo, and the geofence triggering. Submit per your instructor’s current guidance.
Individual reflection (one page maximum). Describe the simulation setup or mission planning work you did, the challenges you faced with SITL integration or geofencing logic, and how simulated behavior compares with what you would expect from real hardware.

B.2.4 Graduate Student Expectations

Graduate participants take the lead on setting up the simulation environment, mentor less experienced teammates on waypoint syntax and QGC failsafe settings, and provide advanced documentation demonstrating more sophisticated simulation features.

B.2.5 How This Lab Was Originally Scored

The original point breakdown (100 points total) is reproduced for reference:

Component	Points	Criteria
SITL setup & geofence	20	Correct Gazebo/QGC integration with an active failsafe
Waypoint navigation	25	Successful execution of the programmed flight path
Video documentation	15	Clear recording showing the mission and the geofence trigger
Team coordination	10	Evidence of collaboration and organization
Individual reflection	30	Thoughtful reflection and meaningful contribution

A graduate-level adjustment of up to ±10 points applied, based on leadership and mentorship.

B.2.6 Practical Notes

Test incrementally — verify waypoint execution before enabling the geofence, so a failsafe trigger is unambiguous when it happens. Document issues (connectivity problems, parameter conflicts) as they occur, and keep the team synchronized by sharing configuration screenshots.

B.3 Edge-Based Target Detection & Deployment

This lab applies the material of Part III — images as data, TinyML deployment, detection pipelines, and real-time edge inference — along with the coordinate-frames chapter that opens Part IV.

B.3.1 Project Overview

This lab transitions from simulation to real-world perception and deployment. Teams develop a complete computer vision pipeline: ingest live or recorded camera frames, train an optimized model to detect targets, and deploy that model onto physical drone hardware or an equivalent edge device. The lab bridges every stage that a deployed perception system passes through — data collection, labeling, model training, edge deployment, and real-time inference — and forces the trade-offs (accuracy versus speed, model size versus performance) that only appear once a model leaves the workstation.

B.3.2 Learning Outcomes

Develop a complete computer vision pipeline from raw data to deployment.
Understand the constraints of edge computing: latency, memory, and power.
Gain experience with model optimization techniques — quantization, pruning, and lightweight architectures.
Work with real-world data collection and labeling workflows.
(Graduate-level extension) Design automated labeling pipelines and optimize deployment efficiency.

B.3.3 Project Requirements

Data collection. Collect or source a dataset relevant to the target detection task — recorded footage, or public datasets where their use is justified. Extract frames from video into an image dataset. Target roughly 20–30 labeled images per contributor at minimum.
Data labeling. Label the dataset with bounding boxes (or segmentation masks) using any standard labeling tool. Deliver the labeled dataset in a standard format such as YOLO or COCO.
Model training. Train a lightweight object-detection model suitable for edge deployment (YOLOv8 is a recommended starting point). Demonstrate the training process and report evaluation metrics: precision, recall, and mean average precision (mAP).
Edge deployment. Deploy the trained model onto physical hardware — a drone’s onboard computer or an equivalent edge device. Implement dynamic camera-frame ingestion (live feed or video stream) with real-time or near-real-time inference. The system must detect and identify targets in real time.
Optimization. Measure frames per second (FPS), latency, and accuracy trade-offs on the deployed hardware.
Demonstration. A video showing the live or recorded camera feed, the model detecting targets in real time, and the deployment running on edge hardware. Submit per your instructor’s current guidance.
Individual reflection (one page maximum). Describe your specific contribution (data, labeling, training, deployment, or another role), the challenges encountered (data quality, labeling consistency, model performance, hardware limitations), the trade-offs you observed (accuracy versus speed, model size versus performance), and what a production-ready version of the system would still need.

B.3.4 Graduate Student Expectations

Automated labeling pipeline. Build an automated or semi-supervised labeling pipeline — Segment Anything (SAM, SAM 2, or SAM 3 where available), Grounding DINO, or any comparable approach — that reduces manual labeling effort by generating initial annotations for human refinement.
Leadership and mentorship. Guide the team on model selection, training pipeline design, and deployment strategy, and assist in debugging hardware/software integration issues.

B.3.5 How This Lab Was Originally Scored

The original point breakdown (100 points total) is reproduced for reference:

Component	Points	Criteria
Data collection & labeling	20	Sufficient, consistent, correctly formatted dataset
Model training & evaluation	20	Demonstrated training with reported metrics
Edge deployment	25	Successful real-time inference on hardware
Optimization	10	Demonstrated performance improvements
Video demonstration	15	Clear evidence of the full pipeline running
Individual reflection	10	Thoughtful, specific reflection

A graduate-level adjustment of up to ±10 points applied, based on automation-pipeline quality, optimization depth, and leadership contribution.

B.3.6 Practical Notes

Start early with data collection and labeling — it is the bottleneck of the whole pipeline. Use small models first (for example, YOLOv8n) before scaling up. Test inference on the target hardware before full training completes, so deployment surprises surface while there is still time to react, and track performance metrics as you iterate.

B.4 Autonomous State Machine Control: Search Grids, Target Harassment, and Reactive Evasion

This lab applies the material of Part IV — search-grid path planning, vector-based evasion, finite state machines and behavior trees, target tracking, and harassment pattern generation — and exercises the integration and diagnostics practices of Part V. It is also the lab closest in spirit to the book’s running example.

B.4.1 Project Overview

This lab transitions from passive perception to active, closed-loop autonomous decision-making. Teams design and implement a comprehensive, hierarchical state machine controlling a drone’s full mission lifecycle in simulation: systematically sweeping an area, executing a dynamic tactical pattern to disperse a target (a simulated goose), and rapidly computing and executing an evasion vector when a threat is encountered. The lab bridges algorithmic path planning, dynamic state switching, and reactive collision avoidance within one simulation environment.

B.4.2 Learning Outcomes

Design and implement deterministic finite state machines (FSMs) or behavior frameworks for complex robotic missions.
Understand and implement systematic area-coverage algorithms, such as lawnmower search grids.
Develop reactive, closed-loop control laws for dynamic target interaction and real-time evasion.
Analyze state-transition latencies and safety guardrails under edge-case flight telemetry.
(Graduate-level extension) Implement hierarchical state structures or behavior trees and optimize dynamic path-replanning algorithms, or take on significant leadership responsibility within the team.

B.4.3 Project Requirements

State machine architecture. Build a robust control framework with explicitly defined states that gracefully handles unexpected sensor drops or telemetry anomalies without crashing the simulated aircraft. Required states: IDLE/TAKEOFF, SEARCH_GRID, HARASS_TARGET, EVADE_THREAT, and LAND/RETURN_TO_HOME. Deliverable: a clear state-transition diagram outlining every trigger, guard condition, and fail-safe.
Search grid execution. Implement a systematic area-coverage algorithm generating a parallel-sweep (lawnmower) path from a defined bounding box. Maintain constant altitude and target forward velocity while minimizing cross-track error, and trigger a state transition immediately upon a simulated detection of the target.
Goose harassment pattern. Once the simulated goose is detected, transition from navigation to an active disruption pattern: track the target’s position (which may be stationary or moving slowly); execute a dynamic harassment profile — an aggressive tracking orbit, close-proximity buzzing passes, or a coordinated herding vector; and maintain strict safety radii so the vehicle never “collides” with the target asset.
Evasion vector computation. During the harassment pattern, a sudden high-priority threat is introduced — an incoming rogue aircraft, a territorial bird, or a simulated geofence breach. The system must instantly override the harassment state upon threat injection, compute a real-time 3D evasion vector perpendicular or opposite to the threat’s trajectory, and execute an aggressive escape maneuver to a designated safe altitude or coordinate point.
Simulation and telemetry logging. Run the full mission loop in a designated simulation environment (Gazebo, AirSim, or ROS/PX4 SITL). Log high-frequency telemetry — \([x, y, z]\) coordinates, the current active state, velocity vectors, and state-transition latency — and demonstrate that the vehicle stays within structurally stable flight envelopes during aggressive maneuvers.
Demonstration video. A screen-recorded video of the simulation executing the full mission lifecycle: a complete, uninterrupted run from takeoff through the search grid, the transition to harassment, threat injection, evasion-vector execution, and a safe return — with an overlaid telemetry terminal or GUI showing real-time state changes. Submit per your instructor’s current guidance.
Individual reflection (one page maximum). Describe your specific technical contribution to the team’s simulation pipeline; the challenges encountered (state-machine race conditions, tuning controller aggressiveness during evasion, simulation-to-reality considerations); the trade-offs you observed — state reactivity and sensitivity to threats versus flight stability and smoothness; and what architectural modifications would be strictly necessary to make the system safe enough to deploy on real hardware.

B.4.4 Graduate Student Expectations

Advanced framework architecture. Implement mission control as a formal behavior tree rather than a flat FSM, demonstrating cleaner modularity and preemption handling.
Stochastic threat evasion. Make the injected threat actively pursue the drone rather than remaining static, requiring dynamic, predictive evasion paths — for example, potential fields or rapid replanning — rather than a single fixed escape vector.

B.4.5 How This Lab Was Originally Scored

The original point breakdown (100 points total) is reproduced for reference:

Component	Points	Criteria
State machine & logic architecture	20	Clean code, robust transition conditions, architectural safety guardrails
Search grid & coverage accuracy	20	Systematic execution with minimal cross-track error
Harassment & evasion algorithms	25	Successful closed-loop tracking and instantaneous, correct 3D escape-vector calculation
Simulation performance & logs	10	Complete high-frequency telemetry, stable flight envelope
Video demonstration	15	Full uninterrupted mission lifecycle with state overlay
Individual reflection	10	Thoughtful, specific reflection

A graduate-level adjustment of up to ±20 points applied, based on behavior-tree complexity, dynamic-evasion capability, and peer leadership.

B.4.6 Practical Notes

Do not build a spaghetti machine: keep state transitions clean, deterministic, and isolated, with clear logging (for example, [STATE CHANGE]: SEARCH -> HARASS) so misbehavior can be debugged visually. Mind the physics — an evasion vector commanding an instant large pitch change would stall or crash a real drone, so bound and smooth step commands even in simulation. And simulate the unexpected: test what happens if a threat is injected exactly as the drone is turning at the edge of the search grid, because edge cases are where state machines lock up.