Autonomy stack
From the outside it looks like one thing: a car that drives. Inside, it is four jobs handed off many times per second.
Picture a restaurant kitchen during a dinner rush. Someone reads the tickets. Someone preps. Someone cooks. Someone plates and sends it out. Each station depends on the one before it, and a mistake at the first station is nearly impossible to fix at the last.
A driving-automation stack works the same way. The first station is perception: turn raw camera pixels into a description of the world — lanes, vehicles, pedestrians, signs, curbs. The second is prediction: guess what each of those moving things will do over the next few seconds. The third is planning: choose a path and a speed given those guesses. The fourth is control: translate the plan into steering angle, accelerator, and brake pressure, smoothly enough that a passenger barely notices.
Same surface symptom — it drove oddly — four different causes.
This framing turns vague complaints into specific questions. A car that brakes for a shadow has a perception problem. A car that hesitates too long at an unprotected left turn has a prediction or planning problem. A car that takes a corner jerkily has a control problem. Same surface symptom — it drove oddly — four different causes.
Modern systems increasingly blur the lines between these stations and learn them together rather than wiring them as separate programs. The four jobs still exist, even when no one can point at a single file that does only one of them.