Sensing everything at maximum resolution all the time is a way to drown your own compute. Atieva's grant US12025747B2 ("Sensor-based control of LiDAR resolution configuration," issued July 2, 2024; inventor Qiang Lu) fences the smarter move: vary the LiDAR's resolution by context — dense scanning where the scene is busy or risky, coarse where it isn't. Atieva is Lucid Motors' engineering arm, so this is a production-EV-maker's autonomy IP.

What makes claim 1 specific — and harder to design around than "adaptive LiDAR" in the abstract — is the cueing sensor it names. The first sensor is not the LiDAR and not an ordinary camera; it is "at least one of an infrared camera or an event-based sensor." Both are change- or salience-detectors: an infrared camera flags thermal anomalies, and an event-based (neuromorphic) sensor fires only on per-pixel brightness changes. Claim 1 uses that first sensor's output, "indicating a portion of surroundings of the vehicle," to drive the LiDAR: it is "providing the first output to a LiDAR of the vehicle having a field of view (FOV)" and then "configuring a resolution of the LiDAR based at least in part on the first output." The cheap, sparse, fast modality tells the expensive, dense modality where to look.

The dependent claims turn "configure a resolution" into actual hardware behavior. Claim 2 introduces a "higher-resolution region (HRR) within the FOV," with the LiDAR "having a higher resolution within the HRR than elsewhere," and defines configuration as positioning that HRR based on the first output — foveation, in other words. Claim 3 places the HRR exactly "at a location of the portion of the surroundings," claim 4 has the cue supply "coordinates" to aim it, and claims 5 and 6 give two physical knobs for the resolution change: "adjusting a scanning rate of the LiDAR at the HRR" or "adjusting a laser pulse frequency of the LiDAR at the HRR." Claim 7 covers a flash-LiDAR embodiment that achieves the same effect by "steering the first FOV toward the part of the surroundings." These are concrete, recited mechanisms, not a vague aspiration to "scan smarter."

“A computer-implemented method comprises: generating first output using a first sensor of a vehicle comprising an infrared camera or an event-based sensor, the first output indicating a portion of surroundings of the vehicle; providing the first output to a LiDAR of the vehicle having a field of view…”— U.S. Patent No. 12,025,747 source

A second, subtler limitation in claim 1 is the data path. The first sensor's output goes to the LiDAR to steer resolution, but it "bypasses at least part of the perception component" — the object-detection, sensor-fusion, and object-tracking stack runs on the LiDAR's third output and a separate second sensor's output, and the bypass is what keeps the cueing loop fast. The cue does not have to wait in the perception queue; it short-circuits to the sensor controller. Claims 8–13 define how each cue type selects its region: the infrared camera flags a portion with "a different temperature," the event-based sensor a portion with "a different pixel change," and in each case the output can carry "only information identifying the portion of the surroundings," keeping the cue lightweight. The system claims (17, and the housing limitation of claim 33 placing "at least the first sensor and the LiDAR…within a common housing") re-fence the architecture as hardware.

This adaptive, attention-like sensing sits at the sensor-control layer, upstream of perception, and ties detector control (G01S 7/487, 7/484) to scene context, with predictive vehicle-control codes (B60W 30/0956, anticipating other road users; 60/0015, scene-based control) marking why the resolution is spent where it is. The LiDAR concentrates a bounded measurement budget where the driving task most needs it, rather than scanning uniformly.

For the control-and-perception beat, adaptive sensing is an elegant systems-level idea — it acknowledges that perception is resource-bounded and that the bound should be allocated by task relevance. The genuinely interesting choice here is the pairing of a salience-detector (thermal or event-based) as the cue: those modalities are good at cheaply answering "where is something changing or warm?" without doing full recognition, which is exactly the question a foveation controller needs answered fast.

From a portfolio angle, it is notable that the assignee is a consumer-EV maker, not a robotaxi pure-play. Lucid building autonomy-sensing IP signals that production carmakers are fencing their own ADAS/autonomy primitives rather than ceding the field to the chip vendors and robotaxi companies. An adaptive-LiDAR-control grant is a small but real stake in that contest.

Caveats. Foveated and adaptive sensing has prior art in imaging and radar; the grant turns on the specific architecture in claim 1 — the IR/event-based cue, the resolution-configuration step, and the perception-bypass path — not on the concept of variable resolution. Breadth depends on whether an accused system actually cues from one of the two named sensor types and how it changes resolution (scan rate, pulse frequency, or FOV steering). It is also worth noting what the claim does not require: it never demands that the LiDAR be a particular brand or that the cue be perfectly accurate, only that the first output "indicate a portion of surroundings" and that the resolution be configured "based at least in part on" it — a deliberately loose linkage that broadens reach even as the named sensor types narrow it. Read the independent claim and claims 2, 5–7 for that mapping.

For the file: an adaptive-LiDAR-control grant from a production EV maker, distinguished by a salience-sensor cue and a perception-bypass fast path. Pull US12025747B2 in the patent record, read claim 1 with claims 2 and 5–7 for the context-to-resolution mapping, and note the assignee — carmakers fencing autonomy primitives is the trend worth tracking.