AIQ
AIQ
Part of the Sensors and Data lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · ⚡ Architect (15–18)
Open by putting the real problem on the table rather than starting with vocabulary:
"Sensors are AI's connection to the physical world — cameras, microphones, motion detectors, and more. Let's examine how sensor fusion enables AI to perceive complex environments."
Follow it with a concrete provocation: "A self-driving car has a camera good enough to read street signs. Why does it also carry radar and lidar, which cost more and add complexity? Wouldn't a really good camera be enough?" Take a few answers without confirming or denying them — this is the question the whole lesson answers, and you want students to hold a hypothesis before you give them the real one.
Give 60 seconds for pairs to brainstorm one situation where a camera alone would fail a self-driving car (fog, direct sun glare, night driving with a broken headlight, an object the exact color of the road). Collect two or three answers on the board. Then reframe: "Every sensor type has situations where it fails. Today's idea, sensor fusion, is about combining sensor types so their weaknesses don't overlap."
Push the framing one step further before moving into content: "This isn't just a self-driving car problem. Any AI system that has to act in the real world — a delivery robot, a health-monitoring wearable, a drone — faces the same tradeoff: which sensors do you pick, and how do you combine what they tell you when they disagree?" That question of disagreement is worth flagging early, because it's the harder half of fusion that most students haven't considered: what happens when the camera says "clear road" and the radar says "object ahead"?
This age band is ready to go past naming sensors and into how they're combined and processed. Structure the activity around the lesson's three scenes, but push each one one level deeper than a straight vocabulary pass.
Move quickly through the fundamentals, since most of this class has met these before: camera (light → digital image), microphone (sound vibration → electrical signal), GPS (satellite triangulation → location, accurate to roughly 3 meters for consumer devices), digital thermometer (heat → a number a system can act on). The useful new point for this age: every one of these is doing the same fundamental job — converting a physical, analog quantity into a discrete digital signal the rest of a computing system can store, transmit, and process.
Go a layer deeper on the accelerometer and compass, since they set up the lesson's payoff concept. "An accelerometer measures acceleration along one or more axes — that's what lets your phone detect tilt, but it's also the core input to a step counter and to games that respond to shaking or motion." Introduce the term IMU (Inertial Measurement Unit): "Phones typically combine an accelerometer, a gyroscope (which measures rotation rate), and a magnetometer/compass (which measures magnetic heading) into one small chip. Combining these three lets a device estimate not just 'am I tilted' but a much fuller sense of its orientation and motion in 3D space." Also cover the heart-rate sensor (photoplethysmography — shining light and measuring how much bounces back off blood flow) and the capacitive touch screen (detecting the tiny electrical charge in a fingertip).
This is where the lesson's real content lives for this age group. Walk through each example asking "what sensors, and why more than one?":
Introduce edge computing explicitly here, since it appears directly in the quiz: "A phone's wake-word detection (like 'Hey Siri') and many IoT sensors process data right on the device — at 'the edge' of the network — rather than sending everything to a cloud server first. This matters for speed (no network round-trip needed) and for privacy (raw sensor data doesn't have to leave the device)." If students ask why not just do everything at the edge: edge devices have limited processing power and battery, so heavier tasks often still go to the cloud.
Tie edge computing back to the farm and home examples to make it concrete rather than abstract: "A soil-moisture sensor on a farm plot might be battery-powered and far from reliable internet. Doing the 'should I water now?' decision right at the sensor, instead of sending every reading to a distant server, means the system still works even if the connection drops — and it doesn't drain the battery sending data constantly." This is the same tradeoff phones make with wake-word detection: a small always-on model runs locally to catch "Hey Siri," and only after that trigger does the fuller request typically get sent to a more powerful cloud-based system.
Small-group task (10 minutes): Give each group one scenario — a delivery drone, a hospital patient monitor, a smart wildfire-detection camera network, a wearable fall-detector for elderly users. Ask them to list which sensors they'd combine and justify at least one fusion choice: what does each sensor cover that the others miss? Groups present their sensor list and one failure case their fusion choice protects against.
The last question doesn't have a clean textbook answer at this level, and that's the point — it's meant to surface that fusion isn't just "combine the data," it's also "decide what to do when sensors conflict," which is an active, unsolved-in-general engineering problem, not a fact to memorize.
Each question here names a specific technical term rather than a general idea, so it's worth checking that students can connect the term to the concrete explanation you gave in the activity — not just recognize the term from the reading.
Close by returning to the opening provocation: "So — why not just use a really good camera for a self-driving car?" By now students should be able to answer with specifics: every sensor type has failure conditions, and fusion means the system doesn't have a single point of failure. Restate the summary line from the lesson: "AI combines data from multiple sensors at once. Self-driving cars mix cameras, lidar, and radar. Phones merge accelerometers with GPS. Combining sensors gives AI a richer view of the world."
Extension activity (20–25 minutes): "Design a fusion system, then break it." Groups design a sensor-fusion system for a scenario of their choice (a search-and-rescue drone, a smart traffic light, a warehouse robot). Require each design to list at least three sensors, one thing each sensor is good at, and one thing it's bad at. After presenting their design, each group swaps with another group and tries to find one realistic scenario that would defeat their sensor combination — fog that blinds a camera and confuses lidar's return signal, a GPS signal lost inside a building, a magnetometer thrown off by nearby metal structures. The original group then proposes a fix: an additional sensor, a fallback behavior, or accepting the limitation and stating it plainly.
This mirrors how real engineering teams stress-test perception systems — nobody ships a fusion design without asking "what breaks this?" first — and it stretches the core lesson into a full period of applied reasoning rather than recall. If time is short, run it as a single whole-class round instead of small groups: pick one scenario, build the sensor list together, then have the class collectively hunt for the failure case.