Intrinsic parameters describe the camera itself — focal length, principal point, and lens distortion coefficients — and stay fixed unless you physically change the lens or sensor. Extrinsic parameters describe where that camera sits on the vehicle: its position and orientation relative to a chosen vehicle reference frame. Both feed the same projection pipeline, but they fail in completely different ways, and an automotive perception stack has to calibrate and monitor them separately because one is essentially permanent while the other drifts every time the car hits a pothole. What Do Intrinsic Parameters Actually Model? Intrinsics answer the question: given a 3D point already expressed in the camera’s own coordinate frame, where does it land on the sensor? That mapping is governed by focal length (in pixels, per axis), the principal point (the optical center’s pixel offset from the image origin), and a distortion model — typically radial and tangential terms for a standard lens, or a fisheye/omnidirectional model for wide-FoV surround cameras. These describe the optics and sensor geometry. They do not change when you drive over a speed bump. They change when the lens is swapped, the sensor is reseated, or a mechanical shock physically shifts the lens-sensor stack — which is rare and usually catastrophic enough to be obvious. In practice, you calibrate intrinsics once per camera unit (often at end-of-line during manufacturing, sometimes per-batch if the optical assembly is tightly toleranced) and treat them as constant thereafter. The one nuance: temperature affects focal length slightly through thermal expansion of the lens barrel. For most ADAS-grade cameras this sits inside the model’s error budget, but for high-precision stereo or long-range depth it’s worth characterizing. Why Do Extrinsics Drift When Intrinsics Don’t? Extrinsics are a rigid-body transform — a rotation and translation — from the camera frame to the vehicle frame. Everything downstream that fuses camera detections with lidar, radar, or a shared bird’s-eye-view grid depends on this transform being correct. And it is exactly the parameter that refuses to stay put. The camera is bolted to a bracket, the bracket to the body, the body flexes. Vibration, thermal cycling of the mount, and physical bumps (curb strikes, minor collisions, a technician leaning on the housing) all shift the pose by fractions of a degree. Fractions of a degree matter: at 50 metres, a 0.5° yaw error puts a projected object roughly 0.4 m off laterally (50 m × tan(0.5°) ≈ 0.44 m) — enough to place a pedestrian in the wrong lane in your fused representation. This is the core asymmetry. Intrinsic parameters describe the camera itself and are fixed unless the lens or sensor changes; extrinsic parameters describe the mounting and drift with vibration, temperature, and physical bumps. Your calibration strategy has to reflect that: intrinsics get a one-time high-accuracy calibration, extrinsics get either continuous online estimation or a monitoring loop that flags divergence. Property Intrinsic Extrinsic What it models Camera optics & sensor Camera pose on vehicle Parameters Focal length, principal point, distortion Rotation + translation (6 DoF) Stability Fixed unless lens/sensor changes Drifts with vibration, temp, bumps Calibration cadence Once per unit (end-of-line) Continuous or monitored Failure mode Rare, usually obvious Frequent, silent Primary risk Manufacturing variance Undetected pose drift What Happens When Extrinsic Drift Goes Undetected? This is where the failure gets dangerous, because it’s silent. A perception model trained on one calibration will silently mis-project 3D-to-2D (or 2D-to-3D) geometry if extrinsic drift goes undetected, because the model has no way to know the camera’s assumed pose has changed. The network still produces confident detections, the projection math still runs without error, and the fused output still looks plausible — it’s just geometrically wrong. Critically, this is a calibration-monitoring gap, not a model-accuracy gap. Retraining the model, adding data, or tuning the detection head does nothing, because the model was never the source of the error. The transform it was handed became stale. Teams burn weeks chasing “accuracy regressions” in the network when the actual defect is a drifted mount and no monitor to catch it. The tell is characteristic: errors that grow with range, correlate with vehicle motion or temperature, and show up as consistent lateral or vertical bias rather than random scatter. Random scatter is a model problem. Systematic, distance-scaled bias is almost always geometry. How Should You Calibrate and Monitor Each in Production? Treat them as two separate lifecycles. Intrinsics — Calibrate at end-of-line with a target board or structured pattern. Store per-unit coefficients with the camera serial. Re-verify only after service events that touch the optics. Extrinsics initial — Calibrate at vehicle assembly against known vehicle-frame references, or use a target-based bay calibration. Extrinsics online — Run continuous estimation using road features (lane markings, horizon, vanishing points) or cross-sensor consistency against lidar/radar to detect divergence. Monitoring threshold — Define a drift budget in degrees/millimetres tied to your worst-case projection error at max operating range, and alarm before it breaches. Cross-check — Periodically validate camera-to-lidar reprojection residuals as an independent signal that extrinsics are still valid. The discriminating design decision is whether you correct extrinsics online or only detect drift and flag for recalibration. Online correction is more robust but adds a feedback loop that can itself fail silently; detect-and-flag is simpler to reason about but requires a service pathway. Most production stacks we’ve reviewed run both: online estimation to correct, plus a hard monitor that trips if the estimator itself diverges. We treat calibration monitoring as part of the same discipline as a broader perception robustness audit — a calibration gap that goes undetected is exactly the kind of silent failure that audit work, part of our computer vision engineering practice, is built to catch before a release. For a related piece on how automation fits into the wider perception validation workflow, see document automation tools in a perception validation workflow: how they work in practice. Frequently Asked Questions Do intrinsic parameters ever need recalibrating in the field? Rarely. Intrinsics only change when the lens or sensor physically changes — a swapped optical assembly, a reseated sensor, or a shock hard enough to shift the lens stack. Thermal effects on focal length exist but usually stay within the error budget for ADAS-grade cameras, so most stacks calibrate intrinsics once per unit and only re-verify after optics-related service. Why can’t the perception model just learn to compensate for extrinsic drift? Because the model has no observability into its own pose. It receives images and an assumed camera-to-vehicle transform; if that transform silently becomes wrong, the model still projects confidently using stale geometry. Drift is a calibration-monitoring problem external to the network, so no amount of retraining or data addition fixes it. How do I tell a calibration error apart from a model-accuracy error? Look at the error structure. Calibration errors are systematic — consistent lateral or vertical bias that grows with range and correlates with vehicle motion or temperature. Model errors tend to be random scatter or class-specific failures. Distance-scaled, biased error is almost always geometry, not the detector. What’s the minimum monitoring you need for extrinsics in production? At minimum, an independent consistency check — camera-to-lidar reprojection residuals or road-feature-based pose estimation — with an alarm threshold tied to your worst-case projection error at maximum operating range. This lets you catch drift before it corrupts fused output, whether or not you also run online correction.
