Ask most teams new to self-driving car machine learning how the system works and you get some version of the same answer: a big neural network watches the road, learns from millions of miles, and eventually learns to drive. Pour in enough data, the reasoning goes, and the model generalises to whatever the real world throws at it. It is a tidy story. It also quietly misplaces where the hard problems actually live. A perception model does not learn to drive. It learns to interpret pixels under a fixed set of geometric assumptions — chief among them, where the camera sits and how it maps the three-dimensional world onto a two-dimensional image. Those assumptions are inputs the model never questions. And the single most common reason a well-trained model degrades on a fleet vehicle is not that the model got worse. It is that one of those unquestioned assumptions shifted, and nothing in the training objective ever taught the model to notice. Understanding what the ML actually learns — and what it takes on faith — is what separates a demo that works on your test track from a system you can field across thousands of vehicles. How does self-driving car machine learning work in practice? Strip away the marketing and a modern perception stack is a pipeline, not a monolith. Cameras (and usually radar and lidar) feed raw sensor data into a chain of stages: preprocessing, a learned detection or segmentation backbone, a fusion step that reconciles multiple sensors into a common frame, tracking that stitches detections across time, and finally a hand-off to prediction and planning. The learned part — the machine learning — lives in a bounded region of that pipeline. Everything upstream and downstream of it is engineering that the model relies on but does not control. What the model learns is a mapping from input tensors to structured output: given this image, produce these bounding boxes, these class labels, this per-pixel segmentation. Trained on datasets like nuScenes or Waymo Open, using architectures ranging from YOLO-family detectors to bird’s-eye-view transformers, the network optimises for accuracy against labelled ground truth. That optimisation is real and it matters. But it is optimisation inside a coordinate system the model assumes is correct. We walk through the full data path in how the perception stack actually works in self-driving cars. The point worth isolating here is narrower: the model’s competence is conditional. It is competent given that the world it sees matches the geometry it was trained under. What is learned, and what is a fixed geometric assumption? The cleanest way to reason about field reliability is to draw a hard line between the two. Component Learned by ML? What it depends on Object detection / classification Yes — trained weights Assumes fixed camera intrinsics and extrinsics Semantic / instance segmentation Yes — trained weights Same geometric assumptions as detection Depth or BEV projection Partly learned, partly geometric Extrinsics define the ground plane and projection Sensor fusion transforms No — calibrated, not trained Extrinsic parameters between sensors Camera intrinsics (focal length, principal point, distortion) No — measured at calibration Physical lens + mounting, drifts over time Camera extrinsics (pose relative to vehicle) No — measured at calibration Physical mount, shifts with vibration, repair, thermal cycling The learned components are what teams instinctively focus on, because they are where the accuracy numbers come from. The fixed components are where field regressions come from. A model trained on images taken through a lens with known intrinsic parameters — focal length, principal point, and distortion — has effectively baked those numbers into its weights. It never receives them as an explicit input it can validate; it simply assumes every image it sees was formed the same way its training images were. Extrinsics are the same story one level up. The model, or the fusion stage feeding it, assumes the camera is mounted exactly where the extrinsic calibration says it is. When a bracket flexes a fraction of a degree after a curb strike, the pixels still look plausible — but the mapping from pixel to world coordinate is now wrong, and the model has no mechanism to detect that. Why does the model treat calibration parameters as inputs it never questions? Because the training objective never asked it to. This is the crux, and it is worth being precise about the mechanism rather than hand-waving at it. During training, every image in the dataset was captured through a specific optical and geometric setup. The loss function rewards the network for producing correct labels on those images. Nowhere in that process is there a term that says “and also flag when the input geometry disagrees with the geometry you were trained under.” The network has no representation of “the expected camera pose” against which it could compare a live frame. It has weights that happen to work well when the geometry matches, and produce confident, plausible-looking, wrong outputs when it does not. This is why the failure is silent. A miscalibrated input does not produce garbage that a downstream sanity check would catch. It produces a bounding box that is a little off, a depth estimate that is biased in one direction, a lane line projected slightly into the wrong position — all with normal-looking confidence scores. The model is doing exactly what it learned to do. It is just doing it on top of a false premise. As a general pattern across the perception systems we have examined, models express no uncertainty about their own geometric preconditions, because uncertainty about the input geometry is simply not in their vocabulary. Once tracking enters the picture, the error compounds. A tracker assumes detections it receives live in a consistent world frame; feed it detections built on drifted extrinsics and the tracker’s association logic quietly breaks even though every individual detection looks acceptable. How does a well-trained model degrade in the field without being at fault? Consider a realistic sequence, framed as an illustrative example rather than a specific reported event. A vehicle ships with a validated perception model that hits its accuracy targets on the qualification set. Months into fleet operation, a subset of vehicles starts showing elevated false negatives on pedestrians at range — the exact failure class safety review most fears. The instinct is to blame the model: retrain, add hard examples, tighten the loss. But the model’s weights have not changed. What changed is that those vehicles accumulated small extrinsic shifts — thermal cycling, road vibration, a windshield replacement that repositioned a camera by a couple of millimetres and a fraction of a degree. The projection from image to world is now systematically biased. Distant objects, where angular error translates into the largest positional error, degrade first. The model is behaving correctly given its inputs; the inputs violate an assumption the model was never taught to police. If you retrain against this, you are optimising against a symptom of geometric drift. You might even appear to improve, because you fed the model examples from the drifted geometry — but you have now coupled your model to a broken calibration state, and the next drift event puts you back where you started. This is the wasted-cycle trap: teams burn retraining effort chasing regressions that no amount of model quality could have fixed. How do you tell a model-quality problem from a calibration-drift problem? You separate them before you touch the model. Here is a diagnostic rubric we apply when a field regression lands and the first question is where does this actually live. Calibration-drift signature — suspect geometry when: The regression is correlated with specific vehicles or a maintenance event (windshield swap, camera repair, collision), not spread uniformly across the fleet. Error grows with distance or eccentricity — worst at the image edges or at range, where small angular errors amplify. The failure appeared without a model or software deployment. Nothing in the ML changed, yet behaviour changed. Re-running the offending frames through the model with corrected calibration parameters restores expected output. Model-quality signature — suspect the model when: The regression is uniform across the fleet regardless of vehicle history. It correlates with a domain the training set underrepresents (a new geography, weather, or object class), not with geometry. It tracks a model or dataset version change — it appeared when you shipped something. Corrected calibration makes no difference; the errors persist on geometrically clean inputs. The measurable payoff of this discipline is concrete: teams that instrument for it can report the share of field regressions traced to calibration versus model quality (an operational measurement from their own monitoring, not a published benchmark), and they cut the retraining cycles wasted on regressions that were never model problems. The second-order win is time-to-detect — catching an assumption-shift event before it propagates into the driving policy. What should a fleet actually monitor to trust the model? Benchmark accuracy tells you the model is competent on a fixed geometry. It tells you nothing about whether that geometry still holds on vehicle 3,412 after eighteen months of service. Fielded trust requires monitoring the assumptions, not just the outputs. In practice that means treating calibration state as a first-class monitored signal alongside model confidence — watching for drift in extrinsics via online estimation, cross-checking sensor agreement (camera-to-radar or camera-to-lidar consistency exposes geometric disagreement the camera alone cannot see), and instrumenting for the distance-dependent error growth that is drift’s fingerprint. The discipline of naming exactly which silent-failure classes matter — and which are calibration versus model — is what a robustness audit formalises. We build this as a [production AI monitoring harness](Production AI Monitoring Harness) scoped to automotive perception, and it sits inside our broader computer vision practice. None of this argues that model quality is unimportant — it argues that model quality is not sufficient, and that a large fraction of what looks like model failure in the field is an assumption failure wearing the model’s clothes. FAQ What matters most about self driving car machine learning in practice? In practice, machine learning occupies a bounded region of the perception pipeline: a trained backbone maps sensor data to structured outputs like bounding boxes, class labels, and segmentation. Everything upstream (preprocessing, calibration) and downstream (fusion, tracking, planning) is engineering the model depends on but does not control. The ML learns to interpret pixels — it does not learn to drive, and its competence is conditional on the geometry it was trained under holding true. What parts of a self-driving perception stack are actually learned by machine learning, and what parts are fixed geometric assumptions? The learned parts are the detection, classification, and segmentation weights, plus part of any depth or bird’s-eye-view projection. The fixed parts are the camera intrinsics (focal length, principal point, distortion) and extrinsics (camera pose relative to the vehicle), which are measured at calibration rather than trained. Sensor-fusion transforms are calibrated too, not learned. Field regressions overwhelmingly originate in the fixed geometric components, not the learned ones. Why does a self-driving perception model treat camera intrinsic and extrinsic parameters as inputs it never questions? Because the training objective never included a term to detect geometric mismatch. The loss function rewards correct labels on training images captured through one specific optical setup; the network builds weights that work when the geometry matches and has no internal representation of the expected camera pose to compare a live frame against. It cannot express uncertainty about a precondition it was never taught exists. How can a well-trained self-driving ML model degrade in the field without the model itself being at fault? The model’s weights never change, but the vehicle’s calibration drifts — thermal cycling, vibration, a windshield replacement that shifts a camera by millimetres. The image-to-world projection becomes biased, degrading distant objects first because angular error amplifies with range. The model behaves correctly given its inputs; the inputs now violate an assumption it was never taught to police, so the failure is silent and confident. How do you tell whether a self-driving perception regression is a model-quality problem or a calibration-drift problem? Look at the signature before touching the model. Calibration drift correlates with specific vehicles or maintenance events, grows with distance or image eccentricity, appears without any model deployment, and disappears when you re-run the frames with corrected calibration. Model-quality problems are uniform across the fleet, track a version change or underrepresented domain, and persist even on geometrically clean inputs. What should a team monitor to trust a self-driving perception model in a real fleet rather than on a benchmark? Monitor the assumptions, not just the outputs. Treat calibration state as a first-class signal alongside model confidence: estimate extrinsic drift online, cross-check camera-to-radar or camera-to-lidar agreement to expose geometric disagreement, and instrument for the distance-dependent error growth that is drift’s fingerprint. Benchmark accuracy confirms competence on a fixed geometry; it says nothing about whether that geometry still holds after months of service. The question a fielded team eventually confronts is not “is the model accurate?” but “how would we know, today, on this specific vehicle, that the model’s geometric premises still hold — and how fast could we tell?” That is the question a robustness audit exists to make answerable.
