AIQ
AIQ
Part of the AI in Transportation lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · 💻 Hacker (11–14)
Open with a framing question rather than a demo: "If I asked you to design the software architecture for a self-driving car, what would you build first?" Let a few students propose answers — most will jump straight to "something that recognizes objects," which is a good setup for the point you're about to make.
"Autonomous systems represent one of AI's most complex engineering challenges — requiring real-time perception, prediction, planning, and control in safety-critical environments. Let's analyze the full autonomy stack."
That's the lesson's own hook for this age band — treat it as a syllabus line for the discussion, not just an intro sentence.
"Object recognition — knowing there's a pedestrian there — is actually the easiest of the four problems I just named. The hard parts are what happen after that: predicting where that pedestrian is about to move, deciding what your car should do about it, and then translating that decision into a precise physical action, all while everything else on the road is also moving. And it all has to happen inside a safety-critical system, meaning a bug here doesn't crash an app — it can cost a life. That's the actual shape of this engineering problem, and it's why it's taken over a decade of serious investment and still isn't fully solved."
This positions the rest of the lesson as an analysis of a real, unsolved systems-engineering problem rather than a tour of cool gadgets — appropriate for an age band where several students may be weighing engineering or CS as a career path.
Worth adding, especially for students considering STEM careers: this problem sits at the intersection of several fields most students think of as separate — computer vision and machine learning (perception), probability and statistics (prediction), control theory and robotics (planning and control), and increasingly, formal methods and safety engineering (verification). Very few real engineering problems require this much breadth from a single team, which is part of why autonomous vehicle companies employ such large, cross-disciplinary engineering staffs, and why the field draws people from surprisingly different academic backgrounds.
The in-app lesson covers three scenes — Self-Driving, Traffic, and Future Travel. For this age band, use them as concrete anchors for the four-stage autonomy pipeline (perception → prediction → planning → control) and the systems-level ideas around it, rather than treating each item as a standalone fact.
Frame this as the perception layer of the stack: fusing heterogeneous sensor modalities (camera, lidar, radar) into a coherent, probabilistic model of the environment — not just "what objects exist" but where they are in 3D space and with what confidence. Perception outputs feed directly into prediction: given the current state of every nearby agent (other cars, cyclists, pedestrians), what are their likely future trajectories over the next few seconds? Prediction uses learned motion models trained on huge datasets of how agents of each type typically move, and it has to output a distribution over possible futures, not a single guess, because a pedestrian might cross the street or might not.
Discussion prompt: "Perception gives you what's out there right now. Why isn't that enough to drive safely — why do you need a separate prediction step?" Guide toward: driving decisions have to account for where things will be by the time your action takes effect, not where they are at this instant — braking distance and reaction time make the "now" picture insufficient on its own.
It's worth being precise about uncertainty here for this age band: a well-designed prediction module doesn't output a single most-likely path for a pedestrian, it outputs a distribution of plausible future paths, each with an associated probability, because committing to one guess and being wrong is far more dangerous than planning conservatively around several possibilities. This is a genuinely different mode of reasoning than deterministic software most students have written themselves, and it's worth pausing on — planning under uncertainty, rather than planning against a single known future, is the core mathematical challenge every stage past perception has to deal with.
This scene sits outside the single-vehicle pipeline — it's optimization over aggregated data across many agents, closer to operations research than to real-time robotics. It's worth naming the distinction explicitly: a self-driving car's stack has hard real-time constraints (a decision has to be made within milliseconds or the vehicle is unsafe), while traffic-light and routing optimization can tolerate more latency because the cost of a slightly stale prediction is inconvenience, not immediate physical risk.
Introduce two concepts that connect back to the hook's framing of this as an unsolved problem: the sim-to-real gap (systems trained and validated extensively in simulation often perform differently in the real world, because simulations can't perfectly capture every real-world sensor artifact, lighting condition, or agent behavior) and occupancy networks (a more recent perception technique — used publicly in Tesla's disclosed architecture, among others — that predicts which small 3D regions of space, or voxels, around the vehicle are physically occupied by something, even before the system has classified what that something is; this gives a layer of generic collision-avoidance that doesn't depend on first correctly labeling every possible object type).
Now have students work through the app's three scenes individually, then in pairs, map each of the twelve items to one of: perception, prediction, planning/control, or system-level optimization. A few items (Decision AI, Smart Trains) genuinely span more than one category — that ambiguity is a feature, not a bug, and worth discussing.
Close with: "What makes autonomous vehicles such a hard engineering problem isn't any single piece — cameras, lidar, and machine learning models all exist and work well individually. It's that all four stages, perception, prediction, planning, and control, have to work correctly together, in real time, in a safety-critical environment, across an effectively unbounded set of real-world situations. That combination is why this remains one of the genuinely unsolved problems in applied AI, even after more than a decade of serious investment from some of the best-funded engineering teams in the world."
Extension activity: Have students pick one real reported autonomous-vehicle incident or disengagement (state DMV disengagement reports, NTSB investigations, and company safety reports are all public and searchable) and write a short analysis identifying which stage of the pipeline — perception, prediction, planning, or control — most plausibly failed, and what a sensor-fusion or software change might address it. This connects the abstract four-stage model directly to a real, documented case, and is a strong entry point for students considering robotics, ML, or systems engineering as a field of study.
For a class discussion extension rather than a written assignment, pose this instead: "Suppose a Philippine city wanted to pilot autonomous shuttle buses on a single, fixed, low-speed route — say, within a university campus or a business park with light traffic. What would make that pilot meaningfully more tractable than a general self-driving car for public roads, and what would the pilot still need to prove before it could expand beyond that one route?" This mirrors how real deployments actually happen — starting with a constrained operational design domain and expanding it only as safety evidence accumulates — rather than an all-or-nothing leap to full autonomy everywhere.