Teaching "Sensors and Data" to Architect mode (ages 15–18)

Hook & Warm-Up

Open with the framing the lesson itself uses, and treat it as an engineering problem statement rather than trivia:

"Sensors give AI its connection to the physical world — from cameras to accelerometers. Let's examine how AI combines sensor data to perceive reality."

Set the stage with a real constraint students will recognize from any embedded or mobile system they've touched: "Every perception system — a phone, a drone, a self-driving car, a fitness tracker — has to solve the same four-stage problem: acquire data from sensors, clean up the signal, extract the features that actually matter, and fuse information across sensor types. And it has to do all of that under real constraints: limited power, limited compute, and a need for the answer fast enough to act on." Write "acquisition → preprocessing → feature extraction → fusion" on the board as the pipeline you'll trace through the whole lesson.

Pose an opening question and let students argue both sides for two minutes before you say anything: "A wearable fall-detector for an elderly user could run its analysis in the cloud, where more computing power is available, or on the device itself, where there's less power but no network delay. Which would you choose, and what does your choice depend on?" There's a real answer that depends on tradeoffs (falls need near-instant response, so latency usually wins) — but the value here is surfacing that the choice is a tradeoff at all, which sets up the constraint-triangle content later.

Add one more layer to the opening before moving into content: point out that "perceive reality" in the hook line is doing real work as a phrase, not just flourish. "AI systems don't have direct access to the world the way you do — everything they 'know' about their environment passes through a sensor first, gets digitized, and gets processed by an imperfect pipeline. Every stage of that pipeline can introduce error or lose information. So when we say an AI system 'perceives' something, we mean it has built an internal, necessarily incomplete model from sensor data — not that it has some equivalent to human sensory experience." This distinction becomes directly relevant in the next lesson, on AI failure modes, so it's worth planting now.

Main Activity

Structure this as a walk through the four-stage perception pipeline, using the lesson's three scenes as worked examples at each stage rather than as a flat vocabulary list.

Stage 1 — Data Acquisition

Cover the sensor types quickly, framing each by what physical quantity it transduces into a digital signal: cameras (photons → pixel intensity values), microphones (air pressure changes → voltage → digital samples), GPS (time-of-flight from multiple satellites → triangulated position, typically accurate to a few meters for consumer receivers), accelerometers (mechanical displacement of a tiny mass → acceleration along an axis), gyroscopes (rotation rate), magnetometers (local magnetic field → heading), and photoplethysmography sensors (light absorption changes in blood flow → heart rate). The unifying idea: acquisition is where physics becomes numbers, and every sensor has a characteristic noise profile and sampling rate that downstream stages must account for.

Stage 2 — Preprocessing

This stage isn't named explicitly in the app's content but is implicit in every "AI reads the pattern" example — flag it directly: "Raw sensor output is noisy. An accelerometer reading jitters even when a phone is still, due to sensor noise and vibration. Before any pattern-recognition happens, that signal typically gets filtered or smoothed." Introduce the Kalman filter here as a concrete, well-known technique: "A Kalman filter is a recursive algorithm that optimally estimates the true state of a system (like a vehicle's position and velocity) from a sequence of noisy measurements over time. It doesn't just average past readings — it maintains a running estimate and its uncertainty, updating both whenever a new measurement arrives. It's used extensively in navigation, robotics, and any system that fuses sensor readings across time."

Stage 3 — Feature Extraction & Stage 4 — Fusion

Use the self-driving car as the central worked example, since it's the richest one in the lesson. Introduce early vs. late fusion explicitly, since it's directly quizzed: "Early fusion combines raw or lightly-processed sensor data before extracting high-level features — for instance, projecting lidar points directly onto a camera image and processing the combined representation together. Late fusion runs each sensor's data through its own separate processing pipeline first (say, a camera-based object detector and an independent radar-based detector), then combines their final outputs or decisions. Early fusion can capture richer cross-sensor correlations but is more computationally demanding and harder to make robust if one sensor fails; late fusion is more modular and fault-tolerant but may miss correlations that only show up in the raw data." Ask students which they'd expect a safety-critical system to favor and why (often a hybrid, precisely because pure early fusion creates a single point of failure).

Bring in temporal synchronization as a practical fusion problem: "If a camera frame and a lidar scan arrive with even a small timestamp mismatch, and the vehicle is moving, fusing them naively can place a detected object in the wrong location — the two sensors are describing the world at slightly different moments. Multi-sensor systems need careful clock synchronization and timestamping for fusion to be meaningful at all." Make the scale of the problem concrete: "A car moving at highway speed covers roughly 20 meters per second. A camera running at 30 frames per second and an IMU sampling at several hundred hertz are, by default, describing slightly different instants — synchronization isn't a minor implementation detail, it's a correctness requirement for fusion to produce a coherent picture of the world at all."

Constraint: Edge ML Deployment

Close the content portion with the resource constraints that shape all of this in practice: "Deploying perception models on-device (edge ML) — as opposed to sending data to a remote server — means balancing three things that pull against each other: latency (how fast you need an answer), power consumption (battery-constrained devices can't run large models continuously), and model accuracy (smaller, faster, lower-power models are generally less accurate than larger ones). A wake-word detector optimizes hard for low latency and power, accepting a simpler, less accurate model, because it only has to distinguish a small vocabulary. A medical diagnostic model might accept higher latency and power draw in exchange for maximum accuracy." Ask students to place the self-driving car's obstacle detection, a phone's wake-word listener, and a wearable's fall detector on this triangle, and justify their placement. Push for specifics rather than a vague ranking: obstacle detection needs both low latency and high accuracy, so it typically accepts higher power draw and dedicated hardware; a wake-word listener sacrifices accuracy for extremely low power since it only needs to catch a short trigger phrase and can hand off harder work elsewhere; a fall detector sits in between, needing low latency for safety but running on a battery-constrained wearable, which usually means a smaller, less accurate always-on model backed by a confirmation step. Naming that tradeoff explicitly for each case matters more here than reaching a single "correct" placement.

Small-group task (10–12 minutes): Assign each group one real system (a smartphone camera app's night mode, a hospital ICU monitor, an agricultural drone doing crop surveys, a smartwatch's fall detector). Have them sketch the full pipeline — which sensors, what preprocessing they'd expect, early or late fusion and why, and where on the latency/power/accuracy triangle the system should sit. Groups present and defend their design choices to the class.

Discussion

• Under what conditions would you choose early fusion over late fusion for a safety-critical system, given that early fusion creates a single point of failure if the fused representation is corrupted?
• A Kalman filter assumes the underlying system's noise is well-modeled (often Gaussian). What happens to a system relying on one when a sensor fails in a way the filter wasn't designed to expect — like a stuck-at-zero fault rather than random noise?
• Edge ML forces a latency/power/accuracy tradeoff. Name a real product decision (existing or hypothetical) where you'd knowingly sacrifice accuracy for lower latency, and justify it.
• Temporal synchronization matters more as sensors sample at different rates (a camera at 30 fps, an IMU at hundreds of Hz). How might you reconcile data with mismatched timestamps in a fusion pipeline?
• Is there a categorical difference between "a sensor with a simple threshold trigger" (a motion light) and "a sensor whose output feeds a learned model," or is it a difference of degree? Defend your position.
• A perception pipeline is only as reliable as its weakest stage. Given the four stages (acquisition, preprocessing, feature extraction, fusion), which do you think is hardest to get right in practice, and why?

Quiz Walkthrough

Every question in this quiz names a real, specific technique — none of them are testable from general AI-familiarity alone. If a student misses one, it's worth going back to where that term was introduced in the activity rather than moving on, since the vocabulary here (Kalman filtering, fusion timing, deployment constraints, synchronization) recurs across robotics, autonomous systems, and any applied ML deployment students may encounter later.

Wrap-Up & Extension

Close by returning to the four-stage pipeline on the board and having the class fill in one real technique per stage from memory: acquisition (any sensor named today), preprocessing (Kalman filtering), feature extraction/fusion (early vs. late fusion, temporal synchronization), and the deployment constraint that shapes all of it (the latency/power/accuracy triangle). Restate the lesson's summary: "Perception pipelines include data acquisition from sensors, preprocessing to clean the signal, feature extraction, and fusion across modalities. Edge computing enables real-time inference on devices with limited power."

Extension activity (25–30 minutes): "Fusion architecture review." Split the class into two sides. One side is assigned to design and defend an early-fusion pipeline for a chosen system (e.g., a delivery robot navigating a sidewalk); the other designs and defends a late-fusion pipeline for the same system. Each side presents their architecture, including which sensors feed in, roughly where synchronization would need to happen, and where their design sits on the latency/power/accuracy triangle. Then open a structured debate: each side has to identify one specific failure mode the other design is more vulnerable to (a corrupted raw fusion representation for the early-fusion side; a missed cross-sensor correlation for the late-fusion side). This turns the abstract fusion distinction into a defended engineering decision, and extends the core 10–15 minute lesson into a full class period of applied systems thinking.