Location-Based Intelligent Vehicle Lighting Interaction System and Method

Abstract

This invention provides an intelligent vehicle lighting interaction system and method based on geolocation services, comprising: a cloud service layer that stores and provides geolocation service data containing specific attribute tags; an environmental perception layer that acquires real-time vehicle perception data; an in-vehicle control layer, including a vehicle / intelligent cockpit domain component and a central decision-making unit, for receiving and initially parsing geolocation service data, and generating lighting control commands through data fusion and decision-making; a vehicle lighting execution layer that drives the intelligent vehicle lights to perform adaptive lighting or interactive actions according to the commands; and a central decision-making unit including data communication, data abstraction, data fusion, rule engine, arbitration distribution, scene management, and configuration diagnosis modules to achieve multi-source data fusion, hierarchical rule decision-making, and security redundancy verification. This invention combines geolocation services with real-time perception data, enabling vehicle lights to anticipate road conditions, understand scenarios, and proactively interact, thereby improving driving safety, interactive richness, and user experience.

Description

Technical Field

[0001] This invention relates to the field of vehicle lighting interaction technology, and more specifically, to an intelligent vehicle lighting interaction system and method based on geolocation services. Background Technology

[0002] Existing intelligent vehicle lights (such as ADB, AFS, and DLP headlights) mainly rely on real-time sensor data from cameras, radar, and other sensors to adjust the light pattern, which is a "passive response." They are unable to predict the static characteristics of the road ahead (such as its narrowness or areas with a fixed high density of pedestrians) or geographical location information related to the destination (such as the type of shops or regional characteristics), and lack predictive active lighting strategies and innovative interactive experiences that are deeply integrated with navigation.

[0003] Patent application CN120935895A discloses an intelligent sensing and control system for vehicle headlights, belonging to the technical field of vehicle headlights. This system includes a sensing layer, a decision-making layer, and an execution layer. The sensing layer monitors the vehicle's attitude in real time through a gyroscope-based attitude sensing unit and obtains road information ahead through a map prediction unit. The decision-making layer fuses multi-source information and generates optimal headlight adjustment commands based on algorithms such as slope compensation, steering follow-up, and map collaboration. The execution layer drives the headlights to achieve horizontal and pitch rotation. However, this patent cannot completely solve the existing technical problems and cannot meet the needs of this invention. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this invention is to provide an intelligent vehicle lighting interaction system and method based on geolocation services.

[0005] The intelligent vehicle lighting interaction system based on geolocation services provided by the present invention includes a cloud service layer, an in-vehicle control layer, a vehicle lighting execution layer, and an environmental perception layer;

[0006] The cloud service layer is used to store and maintain geolocation service data containing specific attribute tags, and to provide the geolocation service data to the vehicle control layer through an application programming interface; The environmental perception layer includes onboard sensors for acquiring real-time perception data of the vehicle and providing it to the onboard control layer. The vehicle control layer includes vehicle-mounted / smart cockpit domain components and a central decision-making unit; The vehicle / smart cockpit domain component is used to receive user commands, initiate data requests to the cloud service layer to obtain the geographic location service data, and transmit the geographic location service data to the central decision-making unit after preliminary analysis. The central decision-making unit is used to receive the pre-analyzed geographic location service data and the real-time sensing data, perform data fusion and decision-making, and generate lighting control commands. The vehicle lighting execution layer includes at least one intelligent vehicle lighting controller, which is used to receive the lighting control command and drive the corresponding intelligent vehicle lighting hardware to perform adaptive lighting or interactive actions. The central decision-making unit includes a data communication module, a data abstraction module, a data fusion module, a rule engine module, an arbitration and distribution module, a scenario management module, and a configuration diagnosis module. The data communication module is connected to the vehicle / smart cockpit domain component, the environmental perception layer, and the vehicle lighting execution layer, and is used to receive the initially parsed geographic location service data and the real-time perception data, and to send instructions to the outside. The data abstraction module is connected to the data communication module and is used to parse the received raw data and convert it into a unified data object within the system. The data fusion module, connected to the data abstraction module, is used to fuse the transformed data to generate and maintain a world model S(t), which includes road state, vehicle state, target state and user state. The rule engine module is connected to the data fusion module and is used to make decisions based on the world model S(t) and the preset rule base, and output the lighting strategy intent. The arbitration distribution module is connected to the rule engine module and the data communication module. It is used to arbitrate and translate the lighting strategy intent, generate specific control commands, and send them to the vehicle lighting execution layer through the data communication module. The scene management module is connected to the data abstraction module, the rule engine module, and the arbitration distribution module, and is used to detect and manage the lifecycle of the interaction scene; The configuration diagnostic module is used to manage system configuration, record logs, and monitor system health status.

[0007] Preferably, the data fusion module includes a spatiotemporal alignment submodule, a state estimation submodule, and a context management submodule; The spatiotemporal alignment submodule is used to unify the timestamp of the input data and convert it to the vehicle coordinate system; The state estimation submodule is used to run the estimation algorithm, calculate and maintain the world model S(t); The context management submodule is used to maintain the dynamically updated world model S(t) and provide a query interface; When constructing the road states in the world model S(t), the state estimation submodule performs the following process: Define state variables Let S(t) be the probabilistic estimate of the road narrowness, and let the state equation be set as follows: The observation equation is ,in For observing noise, k is the step index; The state estimate is updated using the Kalman filter algorithm, and the prediction step is as follows: , , where P is the error covariance and Q is the process noise covariance; The update step is: when the observation value is obtained Calculate the Kalman gain: ,in To observe the noise variance; Updated state estimate: ; Update the estimated error covariance: .

[0008] Preferably, when constructing the target state in the world model S(t), the data fusion module performs the following process: Define the target state vector T, which includes the prior coordinates of the POI in the world coordinate system. and its uncertainty covariance matrix and the position of the POI in the vehicle coordinate system. and its uncertainty ; Prediction steps: Based on vehicle pose and its covariance Predict the position of the POI in the vehicle coordinate system: ,in, It is a rotation matrix; For transformation function, For the vehicle's position components in the world coordinate system; Calculate the uncertainty of prediction: ,in, and Let h be the Jacobian matrix of the transformation function h; Data association steps: For visual observation Calculate its correlation with the prediction Squared Mahalanobis distance: ,in, It is the square of the Mahalanobis distance between the i-th observation and the predicted state of the target at time k; H is the observation matrix; It is the information covariance matrix; selection Correlate the smallest observations; Update steps: If the association is successful, update the state estimate using the Extended Kalman Filter (EKF): Calculate the Kalman gain. ; Update status: ; .

[0009] Preferably, the rule engine module includes a rule base submodule, an inference engine submodule, and a decision output submodule; The rule base submodule is used to store hierarchical decision rules; The inference engine submodule is used to periodically or event-triggeredly obtain the world model S(t) from the data fusion module and match it with the rules in the rule base; The decision output submodule is used to generate the lighting strategy intent after the rule matching is successful; The hierarchical decision-making rules include: L1 security layer rules, which have the highest priority and cannot be overridden, are used to enforce safety lighting actions based on real-time perception data. L2 compliance layer rules are used to adjust lighting parameters according to regulations and environmental conditions; L3 scene layer rules are used to trigger scene-specific lighting actions based on the attribute tags of the geolocation service data.

[0010] Preferably, the inference engine submodule uses fuzzy logic for decision-making, as follows: Define the input fuzzy variables as follows: distance d, with fuzzy set {far, medium, near, very near}; vehicle speed v, with fuzzy set {fast, medium, slow, very slow}; ambient light l, with fuzzy set {bright, medium, dark}. Define the output fuzzy variable as: projection intensity p, and the fuzzy set as {none, weak, medium, strong}; Construct a fuzzy rule base containing multiple IF-THEN rules; When making decisions, the steps of fuzzification, rule evaluation, aggregation, and defuzzification are performed; Deblurring uses the centroid method to calculate the projection intensity output value: Where p is the exact output value after deblurring. c(i) is the membership degree of the output set i, and c(i) is the intensity value corresponding to the centroid of the set.

[0011] Preferably, the rule engine module further includes an online learning mechanism for adjusting projection rule parameters for a specific POI category based on user feedback; A context-based multi-armed gambling machine framework is adopted, and a d-dimensional feature vector is maintained for each POI category c. ,one matrix ,one vector and through Calculate the preference parameter vector ; During decision-making, the UCB score at time t is calculated for each possible action a: ,in, To explore the degree of hyperparameters; Choose the action with the highest score. Execute, and receive a reward after execution. And update the model: , Then recalculate: .

[0012] Preferably, the arbitration distribution module includes an instruction arbitration submodule, an instruction translation submodule, and a command distribution submodule; The instruction arbitration submodule is connected to the rule engine module and is used to receive one or more of the light policy intents, and to arbitrate based on priority and resource conflicts to determine the instruction to be executed. The instruction translation submodule is connected to the instruction arbitration submodule and is used to translate the abstract intent after arbitration into specific control commands that the vehicle light execution layer can understand. The command distribution submodule, connected to the instruction translation submodule and the data communication module, is used to forward the specific control command as communication data and send it to the corresponding intelligent vehicle light controller through the data communication module.

[0013] Preferably, the system performs security redundancy verification by constructing a security sub-world model S_safe(t) independent of business logic, where S_safe(t) includes collision risk state, glare risk state, and regulatory violation state. The update of the safe subworld model S_safe(t) depends only on real-time sensor data from the environment perception layer; Before the arbitration distribution module generates the final lighting control command, it needs to go through a verification process based on S_safe(t); The verification process includes collision risk checks, glare risk checks, and regulatory compliance checks, and follows a fixed priority order of collision risk instructions > glare risk instructions > regulatory compliance instructions > business intent. When a non-empty security instruction is present, the security arbitrator immediately clears and replaces the light intent from the business layer, and the hardware driver layer only receives the final instruction set from the security arbitrator.

[0014] Preferably, the scene management module includes a scene detection submodule, a state management submodule, and a trigger cleanup submodule; The scene detection submodule is connected to the data abstraction module and is used to detect the start and end of the complete interactive scene; The state management submodule is used to manage the state of the scene; The trigger cleanup submodule is connected to the rule engine module and the arbitration distribution module. It is used to notify the rule engine module to load relevant rules when the scene starts, notify the arbitration distribution module to send a cleanup command when the scene ends, and notify the data fusion module to reset the relevant status.

[0015] The intelligent vehicle lighting interaction method based on geolocation services provided by the present invention includes the following steps: Step 1: Receive user commands through the vehicle / smart cockpit domain component, request and obtain geolocation service data containing specific attribute tags from the cloud service layer; Step 2: Obtain real-time perception data of the vehicle through the environmental perception layer; Step 3: The data abstraction module of the central decision-making unit parses the received raw data and converts it into a unified data object within the system; Step 4: The transformed data is fused through the data fusion module of the central decision-making unit to generate and maintain the world model S(t); Step 5: The rule engine module of the central decision-making unit makes a decision based on the world model S(t) and the preset rule base, and outputs the lighting strategy intent; Step 6: Arbitrate and translate the lighting strategy intent through the arbitration and distribution module of the central decision-making unit to generate specific control commands; Step 7: The intelligent vehicle lighting controller of the vehicle lighting execution layer executes the control command to drive the intelligent vehicle lighting hardware to complete adaptive lighting or interactive actions.

[0016] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention combines vehicle lights with geolocation services such as Gaode's "street sweeping list" which contain specific attribute tags. Essentially, it is an interesting exploration of the evolution of vehicle lights from "functional components" to "intelligent components" and "interactive components". The linkage mode of "vehicle lights perceive the environment and map services empower vehicle lights" goes beyond simple lighting. It gives vehicle lights new abilities to perceive the environment, understand intentions, and interact with people, making vehicle lights more intelligent in predicting road conditions and environment. It achieves a leap from "passive response" to "active adaptation" and adds a new dimension to human-vehicle interaction.

[0017] (2) In terms of technology integration, this invention adopts a strategy of deeply integrating the structured attribute data of LBS services such as Gaode "street sweeping list" with real-time vehicle perception data to drive intelligent vehicle lights. This solves the problem that traditional adaptive lighting systems rely solely on real-time sensors, lack predictive capabilities, and cannot cope with static complex road conditions (such as narrow alleys) or provide destination-related services. It achieves the effect of upgrading the vehicle lighting system from "passive response" to "active adaptation", significantly improving the predictive safety of driving and the richness of scene interaction.

[0018] (3) In terms of functional safety, this invention adopts a hierarchical rule engine architecture and gives the safety layer rules the highest decision priority. This solves the potential risk that the implementation of rich human-vehicle interaction functions may conflict with basic driving safety (such as preventing pedestrian glare). It achieves the effect of seamlessly integrating navigation guidance and entertainment interaction functions under the premise of ensuring absolute safety, and realizes the unity of safety and experience.

[0019] (4) In terms of human-computer interaction, this invention uses DLP pixel headlights as the core to transform navigation information and POI attributes (such as star rating and category) into visual road light emblems, light strips and symbols, which solves the problem that traditional vehicle navigation relies only on screen or voice, has a single interaction method and is easy to distract the driver's attention. It achieves the effect of using the natural visual channel to transmit information intuitively, efficiently and emotionally, and greatly reduces the driver's cognitive load.

[0020] (5) At the system integration level, the present invention adopts a modular software architecture to decouple data fusion, strategy decision-making, instruction arbitration and life cycle management, thereby solving the problems of tight internal logic coupling, difficulty in maintenance, updating and expansion of complex multi-functional vehicle lighting systems. This achieves the effect of improving system flexibility, reliability and maintainability, and supports the addition of lighting scenes and interaction modes through OTA online upgrades.

[0021] (6) At the business model level, this invention uses vehicle lights as a new interactive interface to form a closed loop of "data-guidance-experience-feedback" with location services and offline merchants. This solves the problem that traditional vehicle lights are single-function, only cost centers, and cannot create additional value. It achieves the effect of transforming vehicle lights from functional components into value creation platforms, providing a technical foundation for exploring a new business ecosystem of "vehicle-map-store" linkage. Attached Figure Description

[0022] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 System block diagram; Figure 2 A diagram of the central decision-making unit; Figure 3 A diagram showing the interaction relationships between components; Figure 4 Workflow diagram; Figure 5 This is a structural diagram of a headlight; Figure 6 This is the timing diagram for Example 1; Figure 7 This is the timing diagram for Example 2; Figure 8 This is the timing diagram for Example 3; Figure 9 This is a diagram showing the narrowness of the road. Figure 10 For the associated update flowchart; Figure 11 This is a flowchart for security verification. Detailed Implementation

[0023] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0024] This invention combines vehicle lights with geolocation services like Gaode Maps' "Street Scan Ranking," which includes specific attribute tags. Essentially, it's an interesting exploration of how vehicle lights can evolve from "functional components" to "intelligent components" and "interactive components." The interconnected model of "vehicle lights sensing the environment, map services empowering vehicle lights" transcends simple illumination, giving vehicle lights new capabilities to perceive the environment, understand intentions, and interact with people. It allows vehicle lights to more "intelligently" predict road conditions and the environment, achieving a leap from "passive response" to "active adaptation," adding a new dimension to human-vehicle interaction.

[0025] like Figure 1 The diagram shown is a system block diagram of the present invention. This system is a typical cloud-collaborative, vehicle-executed intelligent system. It transforms the rich information from the cloud-based Gaode Maps "street sweeping leaderboard" into specific actions of the vehicle's intelligent lights to achieve safety, guidance, and interaction functions. Its main functions include the following: The cloud service layer's main component is the Gaode Map LBS platform (including "street sweeping rankings" data). On one hand, it is responsible for storing and maintaining the "street sweeping rankings" database, including store names, locations, categories, star ratings, user tags (such as "narrow alleys" and "popular photo spots"), and exclusive logo image data. On the other hand, it provides these structured data services to the vehicle system through standard API interfaces. This data is not only navigation data but also "enhanced map data" containing attribute tags. For example, when a user requests exclusive lighting effects for a specific store, specific projection content (such as graphic files of store logos or star rating badges) is sent to the vehicle.

[0026] The vehicle control layer is the "intelligent hub" of the vehicle, primarily responsible for decision-making and coordination. It includes the vehicle infotainment / smart cockpit domain components and the central decision-making unit (lighting strategy controller) component.

[0027] The vehicle infotainment / smart cockpit domain serves as the entry point for human-machine interaction and data. On one hand, it receives user navigation commands (e.g., a user selects a shop on the "street guide" as their destination via voice or touchscreen), initiates a request to the Gaode cloud to obtain detailed attribute data and route planning for the destination, and receives the returned structured data from the "street guide." On the other hand, it performs preliminary analysis on the acquired structured data, extracting key information useful to the vehicle's lighting system (such as "the destination is a five-star coffee shop" or "the route includes narrow alleys"), and then transmits this information to the central decision-making unit.

[0028] The central decision-making unit is the system's "commander," responsible for formulating lighting strategies. It receives not only "street sweep ranking" attribute data from the vehicle's infotainment system but also real-time vehicle data (such as precise location, speed, and surrounding environment images) from the environmental perception layer. It then fuses the received data and makes decisions based on the built-in "IF-THEN" rule engine, for example: "IF destination is a five-star shop AND distance < 200 meters THEN command DLP headlights project a five-star emblem." Based on the fused information, it determines when, which headlight to trigger, and what action to perform. Finally, it converts the decision into specific, executable control commands (such as CAN bus signals) and sends them to the corresponding headlight controller in the headlight execution layer.

[0029] like Figure 2 The diagram shown is a functional block diagram of the central decision-making unit, which mainly includes the following functional modules: Data Communication Module: Primarily responsible for exchanging information and data with external functional units via different buses (such as CAN, Ethernet) or services (such as Gaode SDK). This includes receiving structured attribute data from the vehicle's "street sweeping leaderboard," such as destination type, star rating, user tags (such as "narrow alley," "parking difficulty," "beautiful night view"), and preset lighting effect IDs. It also receives real-time environmental perception data from onboard sensors, such as high-precision GPS (accurate to lane level position and heading), cameras (identifying vehicles, pedestrians, traffic signs, and lane lines), radar (detecting obstacle distance and relative speed), and IMU (vehicle yaw rate and acceleration). Finally, it receives execution command information from the internal arbitration and distribution module, sends it to the vehicle lighting execution layer via the data bus (such as CAN or FlexRay) for execution, and receives feedback data on its execution status.

[0030] The data abstraction module parses, transforms, and normalizes raw data from different sources and formats (such as CAN signals and JSON data packets) into a unified data object within the system. For example, it abstracts the shop types and GPS coordinates of the "street sweeping list" along with the vehicle's own navigation data into a single target POI object. A POI (Point of Interest) refers to any location on a map that has specific meaning and can be described and labeled. It is not a simple latitude and longitude coordinate, but a coordinate point with attached attribute information. A typical POI object usually contains the following data information: Geographic location—precise coordinates (latitude and longitude) and address, such as the precise location of the shop in the corresponding street sweeping list scenario; Name—the official or commonly used name of the location, such as "XX Cafe" or "YY Bookstore" in the corresponding street sweeping list scenario; Category—describing the type of location, such as food, shopping, tourist attractions, hotels, gas stations, etc. in the corresponding street sweeping list scenario; Attributes / tags—more detailed descriptive information, such as star ratings, user tags (such as "popular spot," "narrow alley," "difficult parking"), contact number, business hours, etc. in the corresponding street sweeping list scenario. Therefore, the POI used in this context refers to a listed shop or location on the "street sweeping list." For the system, when you select a shop on the "street sweeping list" as your navigation destination, the system obtains not just target coordinates, but a PO object rich in attributes. These attributes are key to driving the intelligent headlight decisions: for example, a POI category of "coffee shop" determines the color of the ambient lighting; a POI tag of "narrow alley" triggers the headlights to switch to "narrow road mode" in advance; a POI star rating of "five stars" determines the level of honorary emblem projected by the DLP headlights; and the POI's name and logo serve as the graphic content projected by the DLP headlights. POI is a fundamental and core map data concept. In our innovative solution, the "street sweeping list" is essentially a filtered and processed list of high-quality POIs. Combining the rich attributes of POIs with the capabilities of intelligent headlights is the cornerstone of the entire system's "proactive, predictive, and personalized" lighting and interaction. Data Fusion Module: This is the system's "contextual awareness center," responsible for piecing together fragmented information into a complete picture. It mainly comprises three functional sub-modules: spatiotemporal alignment, state estimation, and context management. The spatiotemporal alignment sub-module is primarily responsible for adding a unified timestamp to all input data and transforming it to a common vehicle coordinate system. The state estimation sub-module is mainly responsible for running lightweight filtering or inference algorithms (such as rule-based state machines) to continuously compute and maintain a unified "world model." This model answers the questions: "Where am I? What is the surrounding environment like? Where am I going?" The context management sub-module is primarily responsible for maintaining this dynamically updated world model and providing query interfaces for other modules.For example, the rules engine can query it at any time: "How far are we from the target store? What is the confidence level of the narrow road?" Data fusion integrates multi-source heterogeneous data into a unified world model, consolidating data from different sources, types, and timestamps into a comprehensive and reliable "environmental understanding" to provide a basis for decision-making. Its core idea is to use state estimation methods based on Bayesian theory, such as Kalman filtering or particle filtering. However, here we apply this concept to a more macroscopic "scene state" estimation. We can create a unified "lighting scene state vector world model" to describe the current environment of the system: World model S(t) = [road state, vehicle state, target state, user state]; The data fusion process is as follows: Step 1: Time synchronization and coordinate alignment. First, all sensing data is synchronized to a unified timestamp via CAN bus or Ethernet and then converted to the vehicle coordinate system.

[0031] Step 2: "Road Status" Update. Street scan data indicates: "Road width < 3 meters after 100 meters ahead" (prior probability). This is verified by the lane width identified in real-time by the vehicle's camera and high-precision map data (observational evidence). A fusion algorithm (such as Kalman filtering) weights and combines these two pieces of information, outputting a more confident estimate of "road narrowness." When prior knowledge aligns with real-time perception, the system's confidence level significantly increases, enabling earlier and more decisive triggering of lighting strategies. The following section uses the "road narrowness" status in the world model as an example to explain this fusion and estimation process in detail.

[0032] We assume that the road condition “narrowness” in S(t) is not a simple Boolean value (yes / no), but a continuous probability estimate, for example, represented by “narrowness probability” (ranging from 0 to 1).

[0033] Step 1: Problem Definition and State Equations; We define "road narrowness" as a state variable x (i.e., S(t).road.narrowness_prob) and assume that it is constant over a short time period (one decision cycle). This is a standard static parameter estimation problem.

[0034] Equations of state: (The state remains unchanged, meaning that the state at time k is equal to the state at time (k-1). Observation equation: ;in, These are observations (measurements from different sensors). It is the observation noise, which follows a Gaussian distribution N(0,R), and its covariance R represents the degree of confidence in the sensor measurement (the greater the noise, the lower the confidence).

[0035] We have two independent sources of observation: 1. Prior observation : Label data from "street sweeping rankings" or high-precision maps (e.g., label confidence is mapped to initial probability values).

[0036] 2. Real-time observation Real-time lane width measurement from camera vision algorithms (e.g., converting the width value into a "narrow probability" using a function).

[0037] Step 2: Detailed explanation of the algorithm process (Kalman filtering); like Figure 9 This refers to the update process of the "road narrowness" state in the world model in each period k: Step 1: Prediction; Since we assume the state remains unchanged, the prediction step is very simple: State prediction: (Use the best estimate from the previous moment directly as the prediction for the current moment); Error covariance prediction: ; Here, Q is the process noise covariance, representing our level of distrust in the assumption that the state is "absolutely invariant." Even without new observations, our confidence level will decrease slightly over time (P increases).

[0038] Step 2: Update (taking camera observation as an example); When new camera observations When it arrives, we use it to revise the prediction: 1) Calculate the Kalman gain K:

[0039] in, This is the noise variance measured by the camera. If the camera is very reliable ( If the noise level is low, the gain K is high, and we are more likely to trust the observation. If the camera noise is high ( If the gain K is large, then the gain K is small, and we will have more faith in the previous prediction.

[0040] 2) Update state estimation:

[0041] This is the core weighted average. The new estimate is based on the old forecast, with an added correction term. The correction term is the observed residuals (the difference between the observed and predicted values) multiplied by a weight (Kalman gain).

[0042] 3) Update the estimated error covariance:

[0043] After each update, our uncertainty P in the state decreases because we have gained new information.

[0044] Step 3: Process prior observations (map labels); "Street sweeping leaderboard" tag data is typically injected as a strong prior during system initialization or when entering a new road segment. It can be processed as follows: 1) As an initial value: At k=0, directly set , ;in, This indicates our level of trust in map labels.

[0045] 2) As a virtual observation: At any given time, if a new high-confidence map label is received, it can be used as a virtual observation with specific... Observations Perform a Kalman update as in step 2. Since map labels are generally very reliable ( (Very small), this update will greatly "pull" the state estimate x "towards" the prior value. .

[0046] Step 3: Integrate into the world model S(t); The world model invokes this "road narrowness estimator" at each decision cycle t (corresponding to k in the algorithm).

[0047] Input: The road.narrowness_prob value in S(t-1) (i.e. ) and its uncertainty, from the perception module From the map module .

[0048] Processing: Perform the Kalman filtering procedure described above.

[0049] Output: The updated version and Write back S(t) as the best estimate of the road narrowness at the current moment and its confidence level.

[0050] Ultimately, the rules engine uses this data-fused, confidence-weighted S(t).road.narrowness_prob value to make its decision. For example: IF S(t).road.narrowness_prob>0.8 AND <Threshold (high confidence); THEN triggers "Narrow Road Lighting Mode".

[0051] This process clearly demonstrates how the world model uses an algorithm (Kalman filtering) to optimally and adaptively weight and merge prior knowledge (map labels) with real-time evidence (camera measurements), thereby deriving a more reliable and robust scene state estimate than a single data source. This is precisely the key to intelligent systems achieving a perception capability of "1+1>2".

[0052] Step 3: "Target Status" Update: The street sweeping leaderboard data provides the precise GPS coordinates and name of the destination. Vehicle GPS and visual odometry provide the vehicle's real-time pose. The system uses a data association algorithm to confirm that the perceived building address or sign is the target on the "street sweeping leaderboard," thus anchoring the abstract navigation point to the real physical world. This is crucial for triggering DLP projection. The following is a detailed mathematical description and algorithmic derivation of this process based on the world model S(t).

[0053] Step 1: Problem definition and state modeling; In the world model S(t), we maintain a "target state list". When the navigation target is set to a POI on the "street sweeping list", we initialize a target state T: Target state vector T: T = [ ]; Wherein, id is the unique ID of the POI (from the "street sweeping list"); type is the type of POI (e.g., "coffee shop"); state is the tracking status (e.g., "initialized", "confirmed"); Here are the prior coordinates of the POI in the world coordinate system (from Amap), where w represents the world coordinate system; The uncertainty covariance matrix of the prior coordinates (representing map accuracy, e.g., ±10 meters). This represents the estimated position of the POI in the current vehicle coordinate system, where v represents the object (here, the vehicle). The uncertainty covariance of this estimated location; is the association confidence (0-1); f is the visual feature descriptor vector of the association.

[0054] Our goal is to update, at each frame k, using the current vehicle pose and visual observations. , and And finally determine whether the association was successful.

[0055] Step 2: Detailed association and update process; This process is a prediction-observation-update cycle, and its core process is as follows: Figure 10 As shown: Step 1: Prediction (world coordinates -> vehicle coordinates prediction); At time k, we know that: 1. Vehicle pose estimation in the world coordinate system (from GPS + visual odometry fusion): and its covariance ; Wherein: the superscript v represents the vehicle, and the subscript w represents the world coordinate system, meaning the pose of the vehicle v in the world coordinate system w; These represent roll, pitch, and yaw angles, respectively. 2. POI world coordinate priors: and its covariance ; Predict the position of the POI in the vehicle coordinate system:

[0056] in, It is a rotation matrix from the world system to the vehicle system, by Decide.

[0057] Uncertainty in the prediction (through error propagation via first-order linearization):

[0058] in, and It is the Jacobian matrix of the transformation function h with respect to the vehicle pose and POI position. This represents the uncertainty of the predicted POI position in the vehicle coordinate system after combining the positioning error and the map error.

[0059] Step 2: Observation (visual inspection); The vision module detects M potential sign or doorplate regions in the image. For each region i: 1. Calculate its 3D position in the camera coordinate system. (Through monocular depth estimation or stereo vision).

[0060] 2. Calculate the noise covariance of this observation. .

[0061] Step 3: Data Association (Key Step); We need to determine which visual observation (If such a problem exists) corresponds to our objective T. This is a typical nearest neighbor association problem, but Mahalanobis distance is used to account for uncertainty: For each observation Calculate its correlation with the prediction The normalized squared information (squared Mahalanobis distance):

[0062] in: At time k, is the square of the Mahalanobis distance between the i-th observation and the predicted state of the target; H is the observation matrix (mapping the vehicle coordinate system to the camera coordinate system). It is the information covariance matrix, which combines the uncertainty of prediction and sensor observation noise; Association logic: 1. Find the The smallest observation j.

[0063] 2. If If the threshold is less than a certain threshold (e.g., a chi-square distribution threshold corresponding to 95% confidence), then the association is accepted. Otherwise, it is considered that no target was detected in this frame.

[0064] Step 4: Update (Extended Kalman Filter EKF); If the association is successful, we use observations. To update the Estimate: 1. Calculate the Kalman gain:

[0065] 2. Update state estimate:

[0066] Correct predictions using observation residuals; 3. Update on uncertainties:

[0067] 4. Update the association confidence:

[0068] in, It is a decay factor (such as 0.9), and a successful association will greatly increase the confidence level.

[0069] If there is no correlation: State estimates regress to predicted values: .

[0070] Confidence decay: .

[0071] Step 3: Decision-making and triggering; In each fusion cycle of the world model S(t), the rule engine queries the target state T: IF High threshold (e.g., 0.85) AND Within the projection range (e.g., within 10 meters in front of the vehicle); THEN determines that "the target has been identified and is located in the projectable area", triggering the DLP projection command.

[0072] This process demonstrates how the world model works as a "dynamic database": 1. It stores prior knowledge from the "street sweeping rankings" ( ).

[0073] 2. It predicts the location where the target should appear at the current moment. ), and quantified the uncertainty ( ).

[0074] 3. It correlates real-time evidence from sensors (visual observations) and fuses the two using an optimal estimation method (extended Kalman filtering).

[0075] 4. It outputs a state estimate with confidence that evolves over time. , This provides a solid and quantifiable basis for high-level decision-making.

[0076] Through this mechanism, the system no longer simply "navigates to a coordinate point," but truly locks onto and confirms a visual target in the physical world, thereby achieving precise and reliable interactive triggering.

[0077] Step 4: Safety Redundancy Verification. This is the most crucial step. Even if the street sweeping leaderboard data doesn't indicate any danger, real-time cameras / radar must be the highest priority input. For example, if the rules engine decides to project a beam, but real-time sensing detects pedestrians in the projection area, the fusion algorithm must prioritize real-time data and suppress or modify the projection instructions to prevent glare. This process essentially involves constructing a parallel safety monitoring world model S_safe(t), independent of the business logic (the "street sweeping leaderboard" scenario) and possessing the highest decision priority. We will formally describe this "real-time verification and rejection of safety layers" process in detail based on the world model S(t).

[0078] Step 1: Define the secure world model and security state; Our first step is to extend the standard world model S(t) to explicitly separate the safety-critical states, which are directly driven by the highest frequency and most reliable sensors.

[0079] The safe subworld model S_safe(t) is defined as: S_safe(t) = [collision risk state, glare risk state, regulatory violation state]. Each state is a vector, for example: 1. Collision risk status: CollisionRisk = [ {object_id, type, position_v, velocity_v, TTC,confidence}, ... ]; Among them, TTC (Time to Collision) is the estimated time to collision, which is the most critical safety indicator; position_v and velocity_v are the position and velocity of the target in the vehicle coordinate system.

[0080] 2. Glare risk status: GlareRisk = [ {target_type (pedestrian / vehicle), position_v, is_in_beam,sensitivity}, ... ]; Here, is_in_beam indicates whether the target is currently within the range of the vehicle's high beam; sensitivity is the target type's sensitivity to glare (pedestrian > oncoming vehicle > same-direction vehicle).

[0081] 3. Status of violation of regulations: RegulationStatus = { high_beam_allowed: bool, urban_area: bool, ...}; Update rules for S_safe(t): Update frequency: synchronized with camera / radar frame rate (e.g., 10~30 Hz), higher than the decision frequency of business logic (possibly 5~10 Hz).

[0082] Update source: Relies solely on real-time sensor data (camera, radar, IMU) and underlying high-precision positioning, completely independent of upper-layer application data such as "street sweeping rankings".

[0083] Algorithm: Uses highly optimized, proven classic algorithms (such as multi-target tracking, TTC calculation, and beam geometry analysis).

[0084] Step 2: Detailed process of security verification (state interaction based on the world model); When the business layer (based on S(t)) generates a lighting action intent (e.g., "project a logo at location p_proj"), it must be verified by S_safe(t) before being finally sent to the hardware. This process is a rigid feedforward-verification-rejection flow.

[0085] Figure 11 This demonstrates how security checks act as a "hard checkpoint," making a final decision before instructions are issued: Verification 1: Collision risk check; Input: S_safe(t).CollisionRisk, the action region p_proj in the business intent.

[0086] algorithm: 1. Check if there are any targets where object.confidence > the threshold and object.TTC < the security threshold (e.g., for a suddenly appearing pedestrian, TTC < 2 seconds). If any exist, immediately trigger the highest priority security response.

[0087] 2. If the business intent involves vehicle dynamics (such as being distracted by projection), its priority can be reduced even if the TTC has not reached the emergency threshold.

[0088] Output: SAFE_CMD_EMERGENCY (includes: disabling all unnecessary light outputs, triggering audible and visual alarms, pre-tensioning seat belts, etc.).

[0089] Verification 2: Glare risk check; Input: S_safe(t).GlareRisk, detailed optical parameters of the business intent (such as projection brightness, beam angle, p_proj).

[0090] algorithm: 1. Geometric calculation: Determine whether p_proj overlaps with pedestrian.position_v or vehicle.position_v recorded in S_safe(t) on the beam path.

[0091] 2. Intensity assessment: Calculate the illuminance of the overlapping area to determine whether it exceeds the threshold for human eye comfort or safety.

[0092] Output: 1. SAFE_CMD_MODIFY_PROJECTION: Modify projection parameters (such as moving it to another location or significantly reducing brightness).

[0093] 2. SAFE_CMD_ADB_SHADING: Controls the ADB matrix headlights to generate a precise dark area at the corresponding position.

[0094] Verification 3: Regulatory compliance check; Input: S_safe(t).RegulationStatus, business intent (e.g., using high beams to assist projection).

[0095] Algorithm: Simple Boolean logic judgment. For example, IF S_safe(t).urban_area == True THENhigh_beam_allowed = False.

[0096] Output: SAFE_CMD_LEGAL_COMPLIANCE (e.g., force switch to low beam mode).

[0097] Step 3: Arbitration and execution of security directives (highest priority overriding); This is the final step in the security logic and the key to achieving "highest priority".

[0098] Security Arbitrator: Receives all security instructions from the S_safe(t) verification module. It follows a fixed, immutable priority order, for example: Collision risk directive > Glare risk directive > Regulatory compliance directive > Business intent; Execution coverage: As long as any non-empty security instruction exists, the security arbitrator will immediately clear and replace the light intent from the business layer.

[0099] The hardware driver layer only receives the final instruction set from the security arbitrator.

[0100] Feedback Mechanism: When the security arbitrator rejects a business intent, it sends a VETO signal to the business layer (S(t)) along with a reason (e.g., pedestrian glare risk). Upon receiving the VETO signal, the business layer's rule engine can learn from it or reset its state, but it must not affect the execution of the current security instruction.

[0101] In short, no matter how enticing the "street sweep ranking" data is, or how intelligent the business logic is, the system's final output must pass through a near-reflexive safety kernel based on the most raw and reliable sensor data. This mechanism ensures that innovative features do not come at the expense of core safety and is the cornerstone of any in-vehicle intelligent system design.

[0102] Data fusion combines static, predictable "street sweeping rankings" data as prior probabilities with dynamic, real-time sensor data as observational evidence, and then uses state estimation methods to weight and merge them to form a more confident and comprehensive world model.

[0103] Rule Engine Module: This is the system's "brain," making judgments based on the current scenario. It mainly comprises three sub-modules: rule base, inference engine, and decision output. The rule base sub-module is primarily responsible for storing all predefined decision rules. These rules are hierarchical, specifying which "lighting action" to perform under what "scenario state." The hierarchical rules are as follows: L1-Security layer rules (highest priority, cannot be overridden), such as: If a real-time camera / radar detects a pedestrian / vehicle ahead, then ADB will be enforced to block the area, prohibiting any entertainment projections.

[0104] If the vehicle speed is greater than 60 km / h, then complex road surface projections are prohibited; only simple navigation arrows are permitted.

[0105] L2 compliance layer rules, such as: If a vehicle enters the oncoming lane, the high beams will automatically turn off (based on regulations and camera data).

[0106] When the IF light sensor detects sufficient ambient light, THEN automatically reduces the projection brightness to save energy and reduce light pollution.

[0107] L3-Scene Layer Rules (the core logic of the "Street Sweeping Ranking" is here), such as: IFS(t). Road Condition. Narrowness == High THEN command: AFS controller switches to "Narrow Road Mode" (light narrowing).

[0108] IFS(u).Vehicle Status.Distance to Target <200m AND S(t).Target Status.Confirmed == True AND S(t).User Status.Speed ​​<20km / h THEN command DLP projection module, call s(t).Target Status.Shop.Effect ID for projection.

[0109] IFS(t).Target Status.Shop.Label contains "Night Market" THEN instruction: Switch the ambient lighting controller to the "Lively" theme color.

[0110] The inference engine submodule is the core of the rule engine's execution. It periodically or triggered by events retrieves the latest "world model" from the context management submodule of the data fusion module and then matches it against rules in the rule base. The decision output submodule is primarily responsible for generating one or more abstract "lighting strategy intents" after a successful match between the latest "world model" and rules in the rule base, such as "Intent: Project brand logo, Priority: Medium, Parameters: {Logo_id: 123, Brightness: 80%)".

[0111] Furthermore, simple systems can directly execute the IF-THEN rules using an "inference engine." However, for more complex scenarios where rule conflicts may exist, "weighted fuzzy logic" or "utility-based decision-making" can be employed. For example, fuzzy decision-making regarding projection timing: Input variables: distance (near, medium, far), vehicle speed (fast, slow), ambient light (bright, dark).

[0112] Output variable: Projection intensity (none, weak, strong).

[0113] Decision-making process: The system does not simply trigger projection at the hard threshold of 200 meters, but rather through fuzzy logic calculation. For example, the condition "very close distance, very slow speed, and very dark environment" will generate a high membership degree (e.g., 0.9) for "execute strong projection", while "medium distance and fast speed" will have a very low membership degree (0.1). Ultimately, the system will output the most reasonable projection intensity based on a weighted score.

[0114] We will formally describe this "projection-triggered decision-making based on fuzzy logic" process in detail, based on the states in the world model S(t).

[0115] The drawback of traditional hard thresholds (such as "projection if distance < 200 meters") is that they are rigid and inflexible. Fuzzy logic allows us to use natural language concepts such as "relatively close" or "very slow speed" for reasoning, making decisions more in line with human intuition.

[0116] Step 1: Define fuzzy variables and membership functions; We select the three states in the world model S(t) that are most relevant to triggering decisions as input variables, and define fuzzy sets for them: 1. Distance (d): The straight-line distance (in meters) from the vehicle to the POI.

[0117] Fuzzy set: {far, medium, near, very near}; Membership function For example, a set can be represented by a trapezoidal function, where the membership degree increases from 0 to 1 between 150 meters and 50 meters, and remains at 1 within 50 meters.

[0118] 2. Vehicle speed (v): The current speed of the vehicle (km / h).

[0119] Fuzzy set: {fast, medium, slow, very slow}; Membership function For example, slow, the membership of the set is 1 between 30 and 10 km / h, and linearly decays to 0 between 40 and 30 and 10 and 0 km / h.

[0120] 3. Ambient lighting (l): Ambient light intensity (lux).

[0121] Fuzzy set: {bright, medium, dark}; Membership function For example, the dark set has a membership of 1 between 0 and 10 lux, and linearly decays to 0 between 10 and 50 lux.

[0122] The output variable is the projection intensity (p), which we define as fuzzy: Fuzzy set: {none, weak, medium, strong}; Membership function For example, a strong set has a membership degree of 1 for strength values ​​between 0.8 and 1.0.

[0123] Step 2: Construct a fuzzy rule base; This is the "brain" of fuzzy logic, consisting of a series of IF-THEN rules that directly encode human decision-making experience. The rules are based on the aforementioned input fuzzy set.

[0124] Example rule base: 1. If the distance is close AND the vehicle speed is slow AND the ambient light is dim, then the projection intensity is strong.

[0125] 2. If the distance is medium, the vehicle speed is slow, and the ambient light is medium, then the projection intensity is medium.

[0126] 3. If the distance is far OR the vehicle speed is fast OR the ambient light is bright, then the projection intensity is zero.

[0127] 4. If the distance is very close and the car speed is very slow, then the projection intensity is strong (regardless of ambient light, because we have arrived at the door).

[0128] 5. If the distance is close, the vehicle speed is medium, and the projection intensity is weak (it may just be passing by, so strong projection interference is not advisable).

[0129] Step 3: Detailed calculation process (taking a certain instantaneous state as an example); Suppose that at time t, the world model S(t) provides the following exact values ​​(defuzzy input): d = 120 meters; v = 15 km / h; l = 5 lux; Step 1: Fuzzification; Calculate the membership degree of each input value to its corresponding fuzzy set.

[0130] For d = 120 meters: Membership degree of a set: (120) = 0.7 (hypothetical value); Membership degree of a near set: (120) = 0.3; The membership degree of a set belonging to another set is 0.

[0131] For v = 15 km / h: (15) = 0.8; (15) = 0.2; For l = 5 lux: (5) = 1.0; Step 2: Rule Evaluation; For each fuzzy rule, calculate its trigger strength (i.e., the membership degree of the "THEN" part output). For AND operations, the minimum value of the input membership degree is usually taken; for OR operations, the maximum value is taken.

[0132] For example, rule 1: IF near AND very slow AND dark; Prerequisites: Near (0.3) AND Very Slow (0.2) AND Dark (1.0); Trigger strength = min(0.3, 0.2, 1.0) = 0.2; Therefore, rule 1 assigns a membership degree of 0.2 to the output strong.

[0133] For example, rule 2: IF AND slow AND in; Prerequisites: Medium (0.7) AND Slow (0.8) AND Medium (0.0) (because the membership degree of the pair with l=5 is 0); Trigger strength = min(0.7, 0.8, 0.0) = 0.0 (rule not triggered); For example, rule 4: IF very close AND very slow; Prerequisites: Very close (0.0) AND Very slow (0.2) (d=120 has a membership degree of 0 for very close). Trigger strength = min(0.0, 0.2) = 0.0; Step 3: Aggregation; The outputs of all rules (each rule assigns a certain membership degree to different sets of projection intensities) are aggregated to form a comprehensive, fuzzy output set.

[0134]

[0135] Assuming rule 3 (far OR fast OR bright) calculates a trigger strength of 0.1, and rule 5 (near AND medium) calculates a trigger strength of 0.3, then the aggregated output fuzzy set is: Strong membership degree = 0.2; The membership degree in the value is 0.0. Weak membership degree = 0.3; The membership degree of none is 0.1; Step 4: Defuzzification; The blurred output set is converted back into a precise projection intensity value (e.g., a number between 0 and 1, where 1 represents full-brightness projection). The centroid method is the most commonly used.

[0136] Calculate the centroid of the output fuzzy set: Projected intensity output value:

[0137] Where p is the precise output value after deblurring (e.g., projection intensity), c(i) is the membership degree of the output set i (none, weak, medium, strong), and c(i) is the strength value corresponding to the centroid of the set (e.g., the centroid of the strong set is 0.9).

[0138] Assume the center of gravity values ​​are: none = 0.0, weak = 0.3, medium = 0.6, strong = 0.9.

[0139] Therefore, the final output intensity = (0.1*0.0 + 0.3*0.3 + 0.0*0.6 + 0.2*0.9) / (0.1+0.3+0.0+0.2) = (0.0 + 0.09 + 0.0 + 0.18) / 0.6 = 0.27 / 0.6 ≈ 0.45; Therefore, for S(t)={d=120, v=15, l=5}, the projection intensity of the fuzzy logic system output is approximately 0.45 (moderately weak), rather than a hard "no projection" or "full bright projection".

[0140] Step 4: Integrate into world models and decision-making; The projected intensity state in this world model S(t) is ultimately used by the rule engine or instruction arbitration module: If S(t).projection intensity > activation threshold (e.g., 0.3) THEN, projection is allowed, and this intensity value is used as a parameter for brightness modulation.

[0141] This process continues every cycle, so when the vehicle approaches from 120 meters to 50 meters, the projection intensity value will smoothly increase from 0.45 to close to 1.0, achieving a stepless, smooth triggering and fade-in effect.

[0142] Through fuzzy logic, the world model S(t) can: 1) Dealing with uncertainty: Quantifying concepts such as "relatively close" and "somewhat slow".

[0143] 2) Achieve a smooth transition: The decision output is continuous, avoiding the abrupt changes caused by hard thresholds.

[0144] 3) Integrate multiple factors for trade-offs: Naturally handle multiple factors that are sometimes contradictory, such as distance, vehicle speed, and ambient light.

[0145] This makes the system exhibit more human-like, flexible decision-making behavior, greatly enhancing the naturalness and comfort of the user experience.

[0146] Furthermore, an advanced system can incorporate an "online learning" mechanism. The system can record user behavior, such as if a user frequently manually turns off projections to a certain type of store. The rules engine can then use machine learning algorithms to automatically adjust the projection rules for that type of store, such as shortening the projection time or reducing the brightness, thereby achieving a personalized experience.

[0147] The following section details how this machine learning algorithm automatically adjusts the projection rule parameters for specific POI categories in the world model based on user feedback. Essentially, the process involves building a "user preference model" and updating it in real time. We employ the contextual multi-armed gambling machine online learning framework, which is well-suited for striking a balance between exploration (trying new strategies) and exploitation (using known preferences).

[0148] Step 1: Problem Modeling and Definition; We will maintain a preference parameter vector for each POI category (such as "coffee shop", "bookstore", "five-star restaurant") or for each specific user. (Where 'c' represents the category or user ID). This parameter directly affects the rules engine's decision regarding projection.

[0149] Define Action: When triggering a projection, the system needs to select one from a set of preset projection strategies. We simplify the strategy into two adjustable dimensions, each with several discrete levels, which can be combined into several "actions": 1. Brightness levels: {Low, Medium, High} → quantized to [0.3, 0.6, 0.9]; 2. Duration: {Short, Medium, Long} → Quantified as [2 seconds, 5 seconds, 8 seconds]; For example, an action could be a={brightness:high, duration:medium}.

[0150] Define the reward: We need to define an instant reward signal This can be used to quantify user satisfaction with the projection. This can be constructed using implicit feedback: Positive Reward (+1): If the projection finishes playing completely and the user does not immediately perform a negative action afterward.

[0151] Strong negative reward (-1): If the user manually turns off the projection immediately after it is triggered (this is the clearest aversion signal).

[0152] Weak negative reward (-0.5): If the user frequently cancels navigation or quickly leaves the POI area during this trip (which may cause discomfort due to projection).

[0153] Objective: To learn a function π(c, s)->a that, given a POI category c and the current scene state s (such as time, vehicle speed), selects the projected action a that yields the maximum expected cumulative reward.

[0154] Step 2: Core Algorithm and Computation Process (Online Learning Loop) We use the LinUCB algorithm, a linear model that leverages contextual features (such as POI category and time). The core computational process is as follows: 1. Feature vector construction: For each decision time t, we construct a feature vector x(t,a) that describes the features of choosing action a under a specific POI category c and scene s.

[0155] For example: x(t,a)=[1, is_category_cafe, is_category_bookstore, is_night, vehicle_speed_low, action_brightness_high, action_duration_medium]^T; This vector includes contextual features (first 5 dimensions) and action features (last 2 dimensions).

[0156] 2. Model maintenance (maintained for each POI category c): It is The matrix (d is the feature dimension) is initialized to the identity matrix λI (λ is the regularization parameter).

[0157] It is The vector is initialized to a zero vector.

[0158] It is a preference parameter vector, through The calculation yielded the result. The physical meaning is: the contribution weight of each feature to obtaining the reward.

[0159] 3. Decision-making process (choosing actions): When the system needs to trigger projection for a POI of category c: For each optional action a, calculate its UCB score:

[0160] First item It is an estimate of expected reward, based on historical data.

[0161] Second item It is an exploration reward that measures the uncertainty of the combination of action features. It is a hyperparameter that controls the degree of exploration.

[0162] Choose the action with the highest score. Perform projection.

[0163] 4. Model updates (learning from user feedback): After the projection is executed, the system observes user behavior and receives a reward. .

[0164] Update matrices and vectors:

[0165]

[0166]

[0167] The essence of this update formula is: if the reward If it's positive, then the action... Corresponding feature weights It will be enhanced if it is negative; if it is negative, the weight will be weakened. Matrix The update is actually accumulating the outer product of all observed features, whose inverse matrix Directly used to calculate the uncertainty of the estimate (the second term of UCB) and the new .

[0168] Step 3: Specific examples and the meaning of the formulas; Assuming that initially, the system has a classification of "coffee shop" as... I know nothing about it.

[0169] Day 1: The user navigates to a coffee shop, and the system selects an action based on the initial rules. ={Brightness: High, Duration: Long}, Feature Vector is The user manually turned off the projector and received... =-1.

[0170] After the update, The weights associated with "high brightness" and "long duration" will decrease significantly.

[0171] Day 2: The user navigated to another coffee shop. The system calculated the UCB score: because The expected reward is now very low (because) (The relevant weight is negative), but the number of exploration items may still be relatively high. They may still get a moderate score.

[0172] action The exploration items for the value {brightness: low, duration: short} are very high.

[0173] The system may choose Explore. The user did not interfere and obtained... =+1.

[0174] After the update, The weights associated with "low brightness" and "short duration" will increase.

[0175] After multiple interactions It will subside. Regarding "coffee shops," The weights corresponding to "low brightness" and "short duration" will remain stable at high positive values, while the weights of "high brightness" and "long duration" will be negative. At this point, the rule engine has essentially "learned" a new rule: for "coffee shop" type POIs, the default is to adopt a low brightness and short duration projection strategy.

[0176] Step 4: Integration with the rules engine; Learned preference parameters Instead of directly replacing manually written core security rules, it functions as a dynamic adjustment layer: Rule parameterization: Converting existing hard rules into parameterized forms.

[0177] IF poi_type==“cafe” THEN ProjectionIntensity=“β_brightness(cafe)”, Duration=“β_duration(cafe)” Wherein, the value of β is determined by This is derived (for example, mapping weights to the probability of a specific brightness level using the softmax function).

[0178] Online updates: After being updated online through the LinUCB process described above, the β value is dynamically adjusted accordingly, achieving personalized adaptation of the rules.

[0179] Safety barriers: The learning process must have absolute boundaries set. For example, the brightness must not be lower than the minimum threshold for safe visibility, and the duration must not be shorter than the minimum time required to complete the information transmission. Learning can only be fine-tuned within these safety boundaries.

[0180] By introducing online learning algorithms like LinUCB, the system is able to: 1. Quantitative Feedback: Transform implicit user behavior (manually turned off) into calculable reward signals.

[0181] 2. Balancing exploration and utilization: intelligently balancing the attempt to try new strategies with the retention of successful strategies.

[0182] 3. Build personalized models: Learn independent preference parameter vectors for different users or POI categories. .

[0183] 4. Dynamically adjust rules: Use the learning results as parameters to fine-tune the decision output of the rule engine in real time.

[0184] This mechanism transforms the system from a static, one-size-fits-all rule into an intelligent agent capable of "reading the room" and providing customized experiences for different users, a key characteristic of advanced human-computer interaction systems. The core formula of the algorithm... and It perfectly encapsulates the two core ideas of online learning: "estimating expected returns based on historical returns" and "encouraging exploration of uncertainty".

[0185] In summary, the rules engine is a layered and prioritized decision-making system. Based on the integrated environment model, it executes decisions ranging from simple IF-THEN to complex fuzzy logic in the order of "safety > compliance > scenario", ultimately outputting precise lighting control commands.

[0186] Arbitration and Distribution Module: This is the system's "command arm," responsible for translating strategies into actions. It mainly comprises three sub-modules: instruction arbitration, instruction translation, and command distribution. The instruction arbitration sub-module receives one or more potentially concurrent "strategic intentions" from the decision output sub-module of the rules engine module. It then arbitrates these intentions based on priority (e.g., the highest safety intention) and resource conflicts (e.g., the DLP cannot project two patterns simultaneously) to determine the final instruction to be executed. The instruction translation sub-module translates the arbitrated, abstract "lighting strategy intentions" into low-level "control commands" that the specific vehicle lighting controller can understand. For example, it translates the "project brand logo" intention into specific API call instructions and graphic data packets sent to the DLP controller. The command distribution sub-module forwards the final control commands into communication data, such as CAN messages, which are reliably sent to the corresponding hardware actuators (DLP, ADB, ambient lighting controller) via the data communication module.

[0187] Scene Management Module: This is the system's "stage supervisor," managing the start and end of tasks. It mainly comprises three sub-modules: Scene Detection, State Management, and Trigger Cleanup. The Scene Detection sub-module is primarily responsible for detecting the start and end of a complete interactive scene. For example, it determines when the "navigate to the street-sweeping list of shops" scene officially begins (when the user sets the destination) and when it completely ends (when the user arrives, cancels navigation, or leaves). The State Management sub-module is responsible for managing the scene's state, such as INIT (initialization), APPROACHING (approaching), EXECUTING (executing), and TERMINATED (termination). The Trigger Cleanup sub-module is responsible for notifying the rules engine module to load relevant rules at the start of the scene; and notifying the arbitration and distribution module to send cleanup instructions (such as turning off projection) and notifying the data fusion module to reset relevant states in preparation for the next task at the end of the scene.

[0188] Configuration and Diagnostics Module: This is the system's "logistics support," ensuring its maintainability and debuggability. It mainly comprises three sub-modules: configuration management, logging and diagnostics, and health monitoring. The configuration management sub-module is primarily responsible for managing all configurable parameters, such as rule bases, distance thresholds, and mapping relationships (which store type maps to which ambient light color), and supports OTA online updates. The logging and diagnostics sub-module is primarily responsible for recording the system's key decision-making processes, data status, and anomaly information, providing data support for troubleshooting and performance optimization. The health monitoring sub-module is primarily responsible for monitoring the operational status of each software module.

[0189] The following concrete example, such as "approaching a five-star coffee shop on a street-sweeping list and projecting its logo," illustrates how the various modules within the central decision-making unit interact and collaborate: Step 1: The data communication module receives a new target POI message (Five-Star Coffee Shop, coordinates xxx) from the vehicle's infotainment system and a vehicle location message from the GPS.

[0190] Step 2: The data abstraction module parses and abstracts these two raw data sets, and transforms them into internally unified navigation targets and vehicle projection events.

[0191] Step 3: The data fusion module subscribes to the above events. Upon receiving new data, it begins data fusion: calculating the distance and relative orientation between the vehicle and the target, and updating its maintained "world model". It determines that "the vehicle is approaching a five-star Po" and updates this scenario state.

[0192] Step 4: The rule engine module is periodically triggered. It queries the data fusion module for the latest scenario: "150 meters from the target, slow speed, dim ambient light." The inference engine matches this scenario with the rule base and finds the rule: IF distance < 200m AND speed < 30kphTHEN, generating the Projecttogo intent (if the vehicle is less than 200m from the target and the speed is less than 30km / h, then a Project Logo intent is generated). Then, the decision output submodule outputs a Project Logo intent to the arbitration and distribution module.

[0193] Step 5: Upon receiving this intent, the arbitration distribution module finds no higher-priority conflicts and translates it into a specific call instruction "DLP_Showmage(logo_123.bin,80%)". This call instruction is then sent to the actual DLP hardware controller via the data communication module.

[0194] Meanwhile, the scene management module activates the "POI navigation scene" as soon as it detects a new navigation destination. It continuously monitors the scene, and when the vehicle has driven more than a certain distance away from the destination, it determines that the scene has ended, triggers the rule engine to generate a StopProjection intent, and finally notifies the DLP to turn off the projection, completing a full interaction loop.

[0195] The headlight execution layer is the system's execution component, responsible for precisely executing actions. Key components include the DLP pixel headlight controller, the adaptive front lighting system (AFS / ADB) controller, and the intelligent traffic light and ambient lighting controller.

[0196] The DLP pixel headlight controller is mainly responsible for high-precision road surface projection and interaction. It receives projection instructions from the central decision-making unit and graphic data from the vehicle's terminal. After parsing and processing, it drives the DMD digital micromirror chip to convert digital graphics into actual optical patterns and accurately project them onto the road surface to display information such as shop logos and navigation arrows.

[0197] The Adaptive Front-lighting System (AFS / ADB) controller is primarily responsible for dynamically adjusting the base lighting to adapt to road conditions. It receives mode switching instructions (such as "switch to narrow road mode") from the central decision-making unit, processes them, and then changes the width, height, and range of the light pattern by controlling the on / off combination of the LED matrix or mechanical servos to achieve safer lighting.

[0198] The intelligent signal light and ambient light controller is mainly responsible for expressing the vehicle status and creating the cabin atmosphere. It receives instructions on light color and dynamic effects from the central decision-making unit, analyzes and processes them, and then controls the taillights and the continuous light strip to achieve specific light signals, or drives the cabin ambient lights to change color and brightness.

[0199] Environmental Perception Layer: The main components are onboard sensors (GPS / cameras / radar), primarily responsible for providing real-time perception data for the vehicle. GPS provides accurate vehicle position and speed, which is the foundation for triggering all location-based services. Cameras and radar detect the surrounding environment in real time, such as oncoming vehicles, pedestrians, and road conditions. This data is mainly used to verify and assist the central decision-making unit's judgment, ensuring that the lighting strategy is executed safely.

[0200] like Figure 3 This diagram illustrates the collaborative processes and interaction relationships among the various components in the system, embodying the closed loop of "data-driven" and "perception-decision-execution." The cloud provides anticipated "static data," while vehicle-side sensors provide "dynamic data." The central decision-making unit integrates and makes decisions, which are ultimately executed precisely by the intelligent headlights, thus achieving a qualitative leap from "passive lighting" to "active interaction" in headlights.

[0201] Specifically, when a user selects a destination (such as a recommended restaurant) from Gaode's "street-sweeping list" on the car's navigation system, the workflow is as follows: Figure 4 As shown, the system immediately retrieves the destination's depth attribute data (e.g., it's a "five-star store") and the entire navigation path's feature data (e.g., passing through a narrow alley) from the cloud. The system doesn't wait until arrival at the destination to begin its operation; it first performs a predictive analysis of the entire path. The core decision-making unit, the lighting strategy controller, asks, "Are there any special road sections ahead?" If the path attributes include tags like "narrow alley" or "densely populated area," it preloads the corresponding "narrow road mode" or "safety enhancement mode." This is equivalent to the headlights preparing in advance to handle complex road conditions. Subsequently, during vehicle travel, the system continuously monitors the vehicle's relative position to the destination using sensors such as GPS. When it determines that the vehicle has entered the vicinity of the destination (e.g., within 500 meters), the lighting strategy controller merges all previously acquired data (destination attributes, preloaded modes, real-time location) to generate the final, precise projection command. Once the final command is sent to the controller of the DLP pixel headlight, the DLP headlight will then activate, converting the digital command into a real optical pattern and accurately projecting a preset "exclusive light emblem" or navigation guidance information (such as the restaurant's star rating and the word "recommended") onto the road surface in front of the vehicle, thus completing a guidance and interaction from data to light.

[0202] This workflow begins with user interaction and goes through a complete "perception-decision-execution" cycle. The system is no longer simply navigating from point A to point B. Instead, it proactively and intelligently drives the headlights based on "precognition" of destination attributes and path characteristics, as well as "perception" of real-time location. It executes the most appropriate optical actions at the right time and in the right place, achieving an upgrade from "arrival" to "experience".

[0203] like Figure 5 The diagram shown illustrates a typical hardware structure focusing on the internal workings of a vehicle headlight controller. It depicts the core components of the intelligent headlight assembly and their collaborative workflow. The entire process begins with the central decision-making unit (i.e., the lighting strategy controller), which acts as the "commander-in-chief." Through the vehicle's CAN bus, it sends control commands (such as "projecting a five-star emblem onto the road" or "switching to narrow-road lighting mode") and related data packets to the headlight master control ECU. The headlight master control ECU is the "local brain" of the headlights themselves; it is responsible for receiving and parsing the commands from the central decision-making unit. Based on the command content, the ECU sends precise drive signals to three different execution modules in parallel or in a time-sharing manner: If road surface projection is required, the ECU will send specific pixel data and synchronization signals to the DLP projection module, driving its core DMD digital micromirror chip to deflect at high speed, converting digital graphics into physical light spots, and accurately projecting them onto the road surface to achieve guidance and interactive functions.

[0204] If the basic lighting pattern needs to be adjusted to cope with complex road conditions, the ECU will send a zone dimming command to the adaptive lighting module to control its LED matrix drive circuit, precisely turn on, off, or adjust the brightness of LEDs in a specific area, thereby realizing advanced functions such as adaptive high beam (ADB) or adaptive front lighting (AFS).

[0205] Meanwhile, the basic lighting module constantly receives commands from the ECU to ensure basic high and low beam illumination, guaranteeing driving safety. In addition, internal sensors (such as temperature and angle sensors) continuously monitor the lamp's operating status and feed this data back to the main lighting control ECU in real time. Based on this, the ECU can perform dynamic compensation and protection (such as reducing brightness in case of overheating), thereby ensuring the entire system can operate stably and reliably for extended periods even in complex environments.

[0206] In summary, this structural diagram clearly demonstrates how intelligent vehicle lighting has evolved from a simple actuator into a complex system integrating computing, driving, and sensing capabilities. Under the command of the "commander-in-chief," each component performs its specific function and works closely together, possessing the ability to perceive and adjust its own state, ultimately transforming data commands into rich, accurate, and safe optical representations.

[0207] Example 1 like Figure 6 As shown, after a user selects a coffee shop on the "Street Ranking," the system completes the entire process from acquiring data to the DLP headlights projecting the coffee shop's logo and the word "Recommended" onto the road in front of the shop.

[0208] Setting: The user is driving and gives the command via voice or touch control from the in-car smart cockpit: "Navigate to Star Cafe".

[0209] Step 1: Intent Triggering and Data Request; 1) User input: Users can enter or specify "Star Cafe" as their destination in the car's navigation interface. This cafe is listed on Gaode's "Street View Ranking" and is a five-star recommended shop.

[0210] 2) Vehicle system request: The vehicle system initiates a navigation request to the Gaode Map LBS platform, and specifically requests to obtain the "street sweeping ranking" enhanced data for the destination.

[0211] 3) Cloud Response: Gaode Cloud confirms "Star Cafe" as a POI and returns a structured data packet, which includes not only standard navigation information (such as coordinates and path) but also attributes specific to the "Street Sweeping Ranking," such as: poi_id: "Cafe_123" poi_name: "Star Cafe"; poi_tier: 5 (five stars); poi_tags: ["Instagrammable spots", "hand-drip coffee"]; recommended_logo_url: "https: / / ... / star_cafe_logo.bin" (Download address for the graphic data of the coffee shop logo); Step 2: In-vehicle data processing and strategy generation; 1) Data Reception and Abstraction: The data communication module receives navigation and "street sweeping list" data packets, which are then parsed by the data abstraction module and converted into an internally unified navigation destination event, which includes the coordinates, store name, star rating and logo download link.

[0212] 2) Scene Activation: The scene management module detects that a new navigation destination has been set and that the destination has a high star rating on the "Street Sweeping Ranking", and then officially activates the "High-Star POI Navigation Scene".

[0213] 3) Continuous data fusion and calculation: Start continuously receiving vehicle's precise location from GPS and vehicle speed data from IMU / wheel speed sensor, and calculate two dynamic variables: real-time distance (the straight-line distance between the vehicle and "Star Cafe") and approach status (combining real-time distance and current vehicle speed to determine whether the vehicle is in a "smooth approach" state).

[0214] 4) Rule Engine Decision: The rule engine is triggered periodically (e.g., every 100 milliseconds). It queries the context management submodule for the current state and receives: "Distance = 150 meters, Vehicle speed = 25 km / h, Scene state = Navigating a high-star POI". The rule engine matches this state with the rule base and successfully hits a core rule: IF Scene == High-star POI navigation AND Distance < 200 meters AND Vehicle speed < 30 km / h AND Ambient light == Dark THEN Generation strategy intent: Project POI Logo Step 3: Command execution and optical rendering; 1) Command Arbitration and Translation: Upon receiving the POI_Logo projection intent, the arbitration and distribution module first checks for higher-priority commands (such as pedestrian occlusion commands for the safety layer). After confirming there are no conflicts, it performs command translation. Using the previously obtained logo URL, it downloads the logo graphic data from the cache or cloud and generates a specific hardware command: DLPProjection(image: star_cafe_logo.bin, position: road surface, brightness: 70%).

[0215] 2) Content Combination (Optional Advanced Function): The system can automatically combine and generate the text or light spot pattern of "Five-Star Recommendation" below the logo graphic to form a complete congratulatory message.

[0216] 3) Command Issuance and Projection: The translated command is sent to the DLP headlight controller via the vehicle bus (such as CAN / FlexRay). The DLP controller drives its DMD chip to convert the digital image signal into an optical signal. Approximately a moment before the user arrives at their destination, a beam of light shines from the headlight, clearly and prominently projecting the "Star Cafe" logo and the word "Recommended" onto the road in front of the store, accurately marking the user's destination and creating a strong sense of belonging and ritual.

[0217] Step 4: Scene wrap-up; 1) Scene End Judgment: The scene management module determines that the "high-star POI navigation scene" has ended when it detects that the vehicle has come to a complete stop (speed is 0) and has remained so for a period of time, or when the user manually cancels the navigation.

[0218] 2) Command Cleanup: This module notifies the rules engine, which then generates a Stop_Projection intent. The command arbitration module ultimately sends a DLP_Off command to the DLP headlight to end the projection, and the system returns to standby mode, waiting for the next task.

[0219] This entire process showcases a complex, data-driven system with a closed-loop perception-decision-execution mechanism. It seamlessly connects cloud services, in-vehicle computing, and hardware execution, transforming a simple navigation experience into an immersive brand experience that is both visually impactful and emotionally satisfying. This is not merely a technological demonstration, but also a microcosm of how future intelligent vehicles, as "mobile living spaces," will enhance user experience.

[0220] Example 2 like Figure 7 As shown, the process is described where the ambient lights automatically turn warm yellow and the taillights activate the "shop search mode" flowing light signal when the vehicle enters the "night market food street" area marked on the "street sweeping list".

[0221] Background: The user has set navigation to "City Center Night Market", or the vehicle is driving on a road approaching the night market. Gaode Maps has marked the "City Center Night Market" area as a "Night Market Food Street" on the "Street Sweeping Ranking".

[0222] Step 1: Area perception and scene preloading; 1) Definition of geofence: In Gaode Maps' "street sweeping ranking" data, "city center night market" is not just a single point, but an area defined by a polygonal geofence, with rich attribute tags: area_id: "NightMarket_001"; area_name: "City Center Night Market Food Street"; area_tags: ["Food hub", "Crowds", "Nighttime economy", "Slow driving"]; suggested_ambient_color: "warm_yellow" (suggested ambient light color); suggested_taillight_mode: "searching_mode" (suggested taillight mode); 2) Data Reception and Abstraction: When a user's navigation path enters or approaches this area, the vehicle's infotainment system will obtain the scene package for this area from the Gaode platform in advance. The data abstraction module parses this into a scene update event for the area, containing all the attributes mentioned above.

[0223] 3) Scene Preloading: Upon receiving this event, the scene management module immediately switches from or prepares to switch from the "Regular Driving Scene" to the "Food Street Area Exploration Scene". It preloads the area labels and suggested lighting configurations into memory, waiting for the trigger conditions to be met.

[0224] Step 2: Trigger condition judgment and strategy decision-making; 1) Area Entry Judgment: The data fusion module continuously compares the vehicle's high-precision GPS location with the geofence boundary of the "night market". When the system determines that the vehicle's front wheels have crossed the virtual boundary, it immediately updates the context state: Current Area Scene = Food Street Area Exploration.

[0225] 2) Environmental status verification: At the same time, the system will confirm that it is nighttime (or the ambient light is weak) through the light sensor to ensure that the lighting changes are appropriate and avoid unnecessary interference during the day.

[0226] 3) Rule Engine Strategy: The rule engine module is triggered immediately upon detecting a change in the current area scene. The complete context it retrieves is: "Entered the Night Market Food Street" area + Ambient Light = Dark + Vehicle Speed ​​= 20 km / h (Low Speed). The engine quickly matches two key area scene rules: Rule A (Ambient Lighting): IF area scene == food street area exploration AND ambient light == dark; THEN generation strategy intent: Set_Ambient_Light_Color (set ambient light color); Parameters: color = warmyellow, brightness = 70%; Rule B (Taillights): IF area scenario == food street area exploration AND vehicle speed < 30 km / h; THEN generation strategy intent: Set_Taillight_Mode (set taillight mode); Parameter: mode=searching_flow (mode=searching flow); Step 3: Multi-lighting system coordinated execution; 1) Command Arbitration and Distribution: The arbitration and distribution module receives two intents simultaneously. After determining there is no priority conflict, they are processed in parallel. It "translates" these abstract intents into commands that their respective hardware can understand: For the ambient light controller: Ambientlight ChangeColor(zone: all, color: 0xFFFFCC, brightness: 0.7) (warm yellow color code); Taillight / through light strip controller: Taillight SetAnimation(mode: flowing_wave, speed: medium, intensity: low); 2) Hardware execution and effect presentation; Inside the car: Almost instantly, the ambient lighting throughout the cabin (footrest lights, door panel lights, center console light strip) transitions smoothly and synchronously from cool tones (such as blue) or white to a warm and inviting yellow. This color scheme is psychologically designed to stimulate appetite and create a relaxing and exploratory atmosphere that perfectly matches the "food street" setting.

[0227] Outside the vehicle: The taillights or continuous light strips switch from a stable red light to a gentle, dynamically flowing light signal. For example, the light strip flows slowly from the center to both sides like waves. This unique visual signal clearly conveys a message to vehicles and pedestrians behind: "This vehicle is searching for a target at low speed and may slow down or stop at any time," serving as a good warning and communication function and improving safety.

[0228] Step 4: Scene preservation and exit; 1) Scene Maintenance: As long as the vehicle remains within the geofence, the scene management module will maintain the scene. The rules engine will continuously monitor vehicle speed and position to ensure that the lighting pattern always matches the scene.

[0229] 2) Scene Exit: Once the vehicle leaves the "Night Market" geofence, the scene management module updates its status. The rules engine is triggered again, generating an intent to restore the default lighting mode. The arbitration distribution module then sends a command to the ambient lighting and taillight controllers to restore the standard mode. The vehicle's interior and exterior lights quietly return to normal driving mode, and the entire scene interaction process is successfully completed.

[0230] This entire process demonstrates how the system understands the driving environment from a macro-regional perspective and creates an immersive experience that feels "when in Rome, do as the Romans do" through the interaction of cabin ambient lighting and external traffic lights. Internally, it enhances the mood and atmosphere of the driver and passengers through color psychology. Externally, it achieves effective communication between the vehicle and its environment through innovative lighting language, enhancing public road safety. This reflects that future intelligent vehicles are no longer isolated entities, but intelligent agents capable of perceiving and interacting with regional characteristics.

[0231] Example 3 like Figure 8 The image shows how to use the "lighting scene tags" of the "street sweeping list" to automatically turn on the side LED lights of the vehicle when it arrives at a store with "insufficient sign lighting".

[0232] Background: The user navigates to "Old Street Private Kitchen". The restaurant has a high rating on the "Street Sweeping Ranking", but user reviews have marked it with the "Lighting Scene Tag: Insufficient Sign Lighting".

[0233] Step 1: Data Acquisition and Risk Prediction; 1) Navigation Settings and Data Retrieval: The user sets "Old Street Private Kitchen" as the destination. The system retrieves detailed information about the POI from Gaode Maps' "Street View Ranking," with a key tag being: lighting_tag: "insufficient facade lighting"; 2) Risk Preloading: The data communication / abstraction module encapsulates this tag as a key security attribute along with the POI coordinates in the navigation destination event. The scene management module then activates the navigation scene and preloads the risk warning "potentially poor destination lighting" into the system.

[0234] Step Two: Continuous Judgment During the Approach Process; 1) Context Fusion and Distance Monitoring: The data fusion module continuously fuses vehicle location, destination coordinates, and lighting_tag. It then calculates two key values: real-time distance (distance between the vehicle and the restaurant) and estimated arrival time (dynamically estimated arrival time based on the current speed).

[0235] 2) Establishment of ambient light benchmark: The system continuously monitors the ambient light intensity through a forward-facing camera and a light sensor to establish a "current area ambient light benchmark", which will serve as an objective basis for subsequent judgment on whether supplemental lighting is needed.

[0236] Step 3: Triggering conditions ripen and strategy decision-making; 1) Triggering condition judgment: The system considers the triggering time to be ripe when the following three conditions are met simultaneously: Condition A (Distance proximity): Real-time distance < 100 meters (entering the final approach phase).

[0237] Condition B (tag exists): NavigationTarget.lighting_tag == "insufficient_facade_lighting".

[0238] Condition C (Environmental Confirmation): Ambient lighting baseline < threshold (the system confirms that the current environment is indeed nighttime or dimly lit).

[0239] 2) Rule Engine Decision: During periodic checks, the rule engine module finds that all the above conditions are true. It immediately matches and executes a security enhancement rule: IF Distance to target < 100 meters AND target.lighting tag == "insufficient facade lighting" AND ambient light == dark THEN Generation strategy intent: Activate_Side_Supplemental_Lighting; Parameter: side=right (default parking on the right side of the road in the driving direction); Step 4: Precise execution and safe supplemental lighting; 1) Command Translation and Distribution: The arbitration distribution module receives this intent. Because this is a safety enhancement function, it has a high priority. It generates precise hardware control commands and sends them to the body domain controller or the dedicated lighting controller: supplementalLighting_On(side: right, mode: wide_angle, brightness: medium).

[0240] 2) Hardware Implementation and Effects: The dedicated supplemental LED light assembly installed on the right front side of the vehicle (such as the rearview mirror base or front fender) is activated. Instead of projecting a long-distance beam, it illuminates the area in front of and to the side of the vehicle (especially sidewalks and building facades) in a wide-angle, soft manner that does not cause glare to others. As the user slowly approaches "Old Street Private Kitchen," the side lights have already illuminated the dimly lit shop sign and entrance area. The driver can easily and safely identify the destination and complete the parking maneuver without straining their eyes.

[0241] Step 5: Exit the function; 1) Exit Mechanism: The exit of this fill light function is triggered by any of the following conditions: Condition 1 (Timeout, e.g., 15 seconds): The system will automatically turn off the auxiliary lights after the vehicle comes to a complete stop (speed is 0) for 15 seconds.

[0242] Condition 2 (Departure): The vehicle accelerates significantly and leaves the destination area (distance > 150 meters). The scene management module notifies that the scene has ended, and the system automatically turns off the auxiliary lights.

[0243] Condition 3 (Manual): The user manually turned off navigation.

[0244] This entire process demonstrates a highly intelligent model of "problem prediction and proactive solution": it resolves the safety hazards and operational stress associated with finding poorly lit destinations in unfamiliar environments, especially at night. It not only prevents drivers from frantically searching, braking suddenly, or stopping dangerously at the last minute, but also proactively improves the driver's blind spots, illuminating potential pedestrians or obstacles, greatly reducing anxiety and operational difficulty in finding the destination, achieving "seamless arrival." It transforms numerous user tags ("insufficient sign lighting") into tangible intelligent services that enhance the user experience for all subsequent users, giving "street-sweeping ranking" data new vitality and practical value. This fully illustrates that future intelligent vehicle lights will not merely "illuminate the road," but also "illuminate the unknown," becoming a key player in eliminating information gaps and improving overall safety.

[0245] Those skilled in the art will understand that, in addition to implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0246] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A location-based intelligent vehicle lighting interaction system, characterized in that, It includes the cloud service layer, the vehicle control layer, the vehicle lighting execution layer, and the environmental perception layer; The cloud service layer is used to store and maintain geolocation service data containing specific attribute tags, and to provide the geolocation service data to the vehicle control layer through an application programming interface; The environmental perception layer includes onboard sensors for acquiring real-time perception data of the vehicle and providing it to the onboard control layer. The vehicle control layer includes vehicle-mounted / smart cockpit domain components and a central decision-making unit; The vehicle / smart cockpit domain component is used to receive user commands, initiate data requests to the cloud service layer to obtain the geographic location service data, and transmit the geographic location service data to the central decision-making unit after preliminary analysis. The central decision-making unit is used to receive the pre-analyzed geographic location service data and the real-time sensing data, perform data fusion and decision-making, and generate lighting control commands. The vehicle lighting execution layer includes at least one intelligent vehicle lighting controller, which is used to receive the lighting control command and drive the corresponding intelligent vehicle lighting hardware to perform adaptive lighting or interactive actions. The central decision-making unit includes a data communication module, a data abstraction module, a data fusion module, a rule engine module, an arbitration and distribution module, a scenario management module, and a configuration diagnosis module. The data communication module is connected to the vehicle / smart cockpit domain component, the environmental perception layer, and the vehicle lighting execution layer, and is used to receive the initially parsed geographic location service data and the real-time perception data, and to send instructions to the outside. The data abstraction module is connected to the data communication module and is used to parse the received raw data and convert it into a unified data object within the system. The data fusion module, connected to the data abstraction module, is used to fuse the transformed data to generate and maintain a world model S(t), which includes road state, vehicle state, target state and user state. The rule engine module is connected to the data fusion module and is used to make decisions based on the world model S(t) and the preset rule base, and output the lighting strategy intent. The arbitration distribution module is connected to the rule engine module and the data communication module. It is used to arbitrate and translate the lighting strategy intent, generate specific control commands, and send them to the vehicle lighting execution layer through the data communication module. The scene management module is connected to the data abstraction module, the rule engine module, and the arbitration distribution module, and is used to detect and manage the lifecycle of the interaction scene; The configuration diagnostic module is used to manage system configuration, record logs, and monitor system health status.

2. The intelligent vehicle lighting interaction system based on geolocation services according to claim 1, characterized in that, The data fusion module includes a spatiotemporal alignment submodule, a state estimation submodule, and a context management submodule; The spatiotemporal alignment submodule is used to unify the timestamp of the input data and convert it to the vehicle coordinate system; The state estimation submodule is used to run the estimation algorithm, calculate and maintain the world model S(t); The context management submodule is used to maintain the dynamically updated world model S(t) and provide a query interface; When constructing the road states in the world model S(t), the state estimation submodule performs the following process: Define state variables Let S(t) be the probabilistic estimate of the road narrowness, and let the state equation be set as follows: The observation equation is ,in For observing noise, k is the step index; The state estimate is updated using the Kalman filter algorithm, and the prediction step is as follows: , , where P is the error covariance and Q is the process noise covariance; The update step is: when the observation value is obtained Calculate the Kalman gain: ,in To observe the noise variance; Updated state estimate: ; Update the estimated error covariance: .

3. The intelligent vehicle lighting interaction system based on location services according to claim 2, characterized in that, When constructing the target state in the world model S(t), the data fusion module performs the following process: Define the target state vector T, which includes the prior coordinates of the POI in the world coordinate system. and its uncertainty covariance matrix and the position of the POI in the vehicle coordinate system. and its uncertainty ; Prediction steps: Based on vehicle pose and its covariance Predict the position of the POI in the vehicle coordinate system: ,in, It is a rotation matrix; For transformation function, For the vehicle's position components in the world coordinate system; Calculate the uncertainty of prediction: ,in, and Let h be the Jacobian matrix of the transformation function h; Data association steps: For visual observation Calculate its correlation with the prediction Squared Mahalanobis distance: ,in, It is the square of the Mahalanobis distance between the i-th observation and the predicted state of the target at time k; H is the observation matrix; It is the information covariance matrix; selection Correlate the smallest observations; Update steps: If the association is successful, update the state estimate using the Extended Kalman Filter (EKF): Calculate the Kalman gain. ; Update status: ; .

4. The intelligent vehicle lighting interaction system based on location services according to claim 1, characterized in that, The rule engine module includes a rule base submodule, an inference engine submodule, and a decision output submodule; The rule base submodule is used to store hierarchical decision rules; The inference engine submodule is used to periodically or event-triggeredly obtain the world model S(t) from the data fusion module and match it with the rules in the rule base; The decision output submodule is used to generate the lighting strategy intent after the rule matching is successful; The hierarchical decision-making rules include: L1 security layer rules, which have the highest priority and cannot be overridden, are used to enforce safety lighting actions based on real-time perception data. L2 compliance layer rules are used to adjust lighting parameters according to regulations and environmental conditions; L3 scene layer rules are used to trigger scene-specific lighting actions based on the attribute tags of the geolocation service data.

5. The intelligent vehicle lighting interaction system based on location services according to claim 4, characterized in that, The inference engine submodule uses fuzzy logic for decision-making, as follows: Define the input fuzzy variables: distance d, with fuzzy set {far, medium, near, very near}; vehicle speed v, with fuzzy set {fast, medium, slow, very slow}; Ambient lighting l, with a fuzzy set of {bright, medium, dark}; Define the output fuzzy variable as: projection intensity p, and the fuzzy set as {none, weak, medium, strong}; Construct a fuzzy rule base containing multiple IF-THEN rules; When making decisions, the steps of fuzzification, rule evaluation, aggregation, and defuzzification are performed; Deblurring uses the centroid method to calculate the projection intensity output value: Where p is the exact output value after deblurring. c(i) is the membership degree of the output set i, and c(i) is the intensity value corresponding to the centroid of the set.

6. The intelligent vehicle lighting interaction system based on location services according to claim 4, characterized in that, The rule engine module also includes an online learning mechanism for adjusting projection rule parameters for specific POI categories based on user feedback. A context-based multi-armed gambling machine framework is adopted, and a d-dimensional feature vector is maintained for each POI category c. ,one matrix ,one vector and through Calculate the preference parameter vector ; During decision-making, the UCB score at time t is calculated for each possible action a: ,in, To explore the degree of hyperparameters; Choose the action with the highest score. Execute, and receive a reward after execution. And update the model: , Then recalculate: .

7. The intelligent vehicle lighting interaction system based on location services according to claim 1, characterized in that, The arbitration distribution module includes an instruction arbitration submodule, an instruction translation submodule, and a command distribution submodule; The instruction arbitration submodule is connected to the rule engine module and is used to receive one or more of the light policy intents, and to arbitrate based on priority and resource conflicts to determine the instruction to be executed. The instruction translation submodule is connected to the instruction arbitration submodule and is used to translate the abstract intent after arbitration into specific control commands that the vehicle light execution layer can understand. The command distribution submodule, connected to the instruction translation submodule and the data communication module, is used to forward the specific control command as communication data and send it to the corresponding intelligent vehicle light controller through the data communication module.

8. The intelligent vehicle lighting interaction system based on location services according to claim 1, characterized in that, The system performs security redundancy checks by constructing a security sub-world model S_safe(t) independent of business logic. S_safe(t) includes collision risk state, glare risk state, and regulatory violation state. The update of the safe subworld model S_safe(t) depends only on real-time sensor data from the environment perception layer; Before the arbitration distribution module generates the final lighting control command, it needs to go through a verification process based on S_safe(t); The verification process includes collision risk checks, glare risk checks, and regulatory compliance checks, and follows a fixed priority order of collision risk instructions > glare risk instructions > regulatory compliance instructions > business intent. When a non-empty security instruction is present, the security arbitrator immediately clears and replaces the light intent from the business layer, and the hardware driver layer only receives the final instruction set from the security arbitrator.

9. The intelligent vehicle lighting interaction system based on location services according to claim 1, characterized in that, The scene management module includes a scene detection submodule, a status management submodule, and a trigger cleanup submodule; The scene detection submodule is connected to the data abstraction module and is used to detect the start and end of the complete interactive scene; The state management submodule is used to manage the state of the scene; The trigger cleanup submodule is connected to the rule engine module and the arbitration distribution module. It is used to notify the rule engine module to load relevant rules when the scene starts, notify the arbitration distribution module to send a cleanup command when the scene ends, and notify the data fusion module to reset the relevant status.

10. A smart vehicle lighting interaction method based on geolocation services, characterized in that, The intelligent vehicle lighting interaction system based on location services, applied to any one of claims 1 to 9, comprises the following steps: Step 1: Receive user commands through the vehicle / smart cockpit domain component, request and obtain geolocation service data containing specific attribute tags from the cloud service layer; Step 2: Obtain real-time perception data of the vehicle through the environmental perception layer; Step 3: The data abstraction module of the central decision-making unit parses the received raw data and converts it into a unified data object within the system; Step 4: The transformed data is fused through the data fusion module of the central decision-making unit to generate and maintain the world model S(t); Step 5: The rule engine module of the central decision-making unit makes a decision based on the world model S(t) and the preset rule base, and outputs the lighting strategy intent; Step 6: Arbitrate and translate the lighting strategy intent through the arbitration and distribution module of the central decision-making unit to generate specific control commands; Step 7: The intelligent vehicle lighting controller of the vehicle lighting execution layer executes the control command to drive the intelligent vehicle lighting hardware to complete adaptive lighting or interactive actions.

Images