AIQ
AIQ
Part of the AI in Transportation lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · ⚡ Architect (15–18)
Open by asking: "How many of you have heard the term 'self-driving car'? Now — how many of you could actually explain what 'self-driving' means, technically?" Let the ambiguity sit for a moment; most students will realize they've used the phrase loosely.
"Self-driving cars use cameras, radar, and AI to navigate roads in real time. Let's explore how autonomous vehicles work and what challenges they face."
That's the lesson's own hook for this age band — deliver it as a direct statement of what you're about to unpack, not a soft warm-up. This age group responds better to "here's a real engineering problem" framing than to a story.
"Here's the thing most people get wrong: there isn't one kind of 'self-driving.' There's an actual scale, from zero automation to full automation, and almost everything on the road right now — including cars marketed as having 'self-driving' or 'autopilot' features — sits in the middle of that scale, not at the top. By the end of this lesson you'll know exactly where the line is, and why the hardest part of this problem isn't the easy 95% of driving."
This sets up the SAE levels and the "long tail problem" as the two ideas the whole lesson is really building toward.
Follow up with a quick, concrete framing question: "If a car can steer itself and keep a safe following distance on the highway, but the manual says you must keep your hands on the wheel and stay ready to take over at any time — is that car 'self-driving'?" Most students will initially say yes; push back gently with "then whose job is it, legally and practically, if something goes wrong?" This is the exact ambiguity the SAE levels exist to resolve, and it's worth leaving the question slightly open here so the Main Activity can answer it properly.
The in-app lesson runs three scenes — Self-Driving, Traffic, and Future Travel — each with four AI/not-AI items and a technical fact. For this age band, use each scene as a jumping-off point into the underlying engineering concept rather than just confirming the AI/not-AI label.
Introduce the term sensor fusion: combining data from multiple sensor types (camera, lidar, radar) because each has different strengths and failure modes. Cameras are cheap and resolve fine detail (reading a sign, a traffic light's color) but struggle with glare, darkness, and don't directly give distance. Lidar gives precise, lighting-independent 3D distance data via time-of-flight measurement, but is costly and can degrade in heavy rain or snow. Radar is weaker on resolution but reads through fog and rain well and measures velocity directly via the Doppler effect. No single sensor is sufficient on its own, which is why production systems combine them.
Discussion prompt: "If lidar gives such a precise 3D map, why do these systems still bother with cameras at all?" Guide toward: lidar tells you something is there and how far away, but not what it is or what color a light is — reading a stop sign's text or a light's color still needs a camera.
It's worth naming radar here too, even though the app's item list for this scene doesn't include it by name: radar uses radio waves rather than light, which lets it see through fog, heavy rain, and dust far better than either cameras or lidar, and it can measure a target's speed directly via the Doppler effect — how much the reflected wave's frequency shifts based on relative motion. Radar's resolution is much coarser than lidar's, so it's typically used for tasks like detecting a vehicle's speed and rough position at long range, complementing rather than replacing the other two sensors.
Frame this scene as "AI optimizing a system, not just one vehicle." Smart traffic lights and route-planning apps aren't perceiving the physical world with cameras the way a self-driving car does — they're processing aggregated data (sensor counts at an intersection, or millions of phones' location and speed data) to make a system-wide decision. It's a different problem from perception: it's optimization over data that's already been collected, at a much larger scale.
This is also a good moment to raise a genuine tradeoff: optimizing traffic for the whole system doesn't always feel fair to any single driver. A route-planning app might send you down a longer road because it's slightly faster on average, or a smart intersection might favor the busier direction, meaning cars on the quieter side wait longer even though they arrived first. Ask students: "Is it okay for an AI system to make some individual trips slightly worse if it makes the overall system faster for everyone? Who gets to decide that tradeoff?" There's no single correct answer, but the question is a realistic preview of decisions traffic engineers and city planners actually have to make.
Introduce V2X (vehicle-to-everything) communication: vehicles exchanging data directly with infrastructure and with each other — a car broadcasting "I'm braking hard" to the car behind it, or a traffic light broadcasting its upcoming phase change to approaching cars — for coordinated driving that goes beyond what any single vehicle's own sensors could perceive on their own. Note the practical limitation worth raising with students: V2X only helps once enough vehicles and infrastructure actually support it — a single V2X-equipped car surrounded by ordinary vehicles gets very little benefit, which is the same "network effect" problem that shows up whenever a new communication standard needs wide adoption to be useful (similar to how a single household with a fax machine got no benefit until other households had one too).
Now let students work through the app's version of all three scenes individually, then regroup and have them explain, for one item each, which category of technical concept it falls under: perception (sensing the immediate environment), system-level optimization (traffic/routing), or coordination (V2X).
Close with: "The core idea today is that 'self-driving' isn't one thing — it's a scale, from zero automation to full automation, and the technology on the road right now is mostly in the middle of that scale. The engineering challenge isn't making a car handle a normal highway; it's the rare, weird situations — the long tail — that are hardest to prepare for, which is exactly why safety testing for real autonomy takes so much longer than people expect."
Extension activity: Split the class into small groups and assign each group a specific SAE level (0 through 5). Each group researches one real consumer or commercial system that roughly matches their assigned level (e.g., basic cruise control for Level 1, Tesla's Autopilot or GM Super Cruise for Level 2, Mercedes Drive Pilot for Level 3 in permitted jurisdictions, Waymo's robotaxi service for Level 4) and presents to the class: what the system actually does, and — critically — what it still requires a human to do. This turns the abstract SAE scale into concrete, checkable claims about real products.
For groups that finish early, add a second task: find one recent news article (from the last two or three years) about a self-driving vehicle incident, recall, or regulatory decision, and identify which SAE level the vehicle involved was operating at when the article was written. This trains a genuinely useful skill — reading past a headline's dramatic framing to find the specific, checkable technical claim underneath it, which is exactly the skepticism this age band should be building toward with any AI-related news story, not just ones about cars.