A matrix car lamp intelligent control system based on distribution

Abstract

The application relates to the field of automobile lighting technology, in particular to a matrix car lamp intelligent control system based on distribution, which comprises a driving data coding module, a driving state information of the car is acquired, and a first state code is generated based on the driving state information; and a coded light field projection control module controls the matrix car lamp of the car; the first state code is generated through the vehicle driving state information, the first coded light field carrying the code is projected by the matrix car lamp, the visualization transmission of the vehicle state is realized, the accurate transmission of the vehicle state is realized through the coded light field, the insufficient information transmission caused by the singleness of the traditional light signal is avoided, the collision risk is reduced, the surrounding incident light is sensed in real time, the second coded light field projected by other vehicles is analyzed and decoded to obtain the second state code, the bidirectional interaction of the cross-vehicle state information is realized, the state information of the self and the surrounding vehicles is combined, the lighting area is dynamically adjusted, the complex road conditions can be coped with, and the pertinence and practicability of the lighting are improved.

Description

Technical Field

[0001] This invention relates to the field of automotive lighting technology, and more specifically to a distributed matrix headlight intelligent control system. Background Technology

[0002] Distributed matrix headlight intelligent control is a headlight control system based on distributed architecture and intelligent algorithms. Its core is to decompose the vehicle's matrix headlights into multiple independent and controllable light-emitting units. Through precise grouping, dynamic adjustment and collaborative control of each unit, the system can achieve intelligent adaptation of the light in terms of brightness, angle and range to meet the lighting needs of different driving scenarios, while also taking into account energy saving and safety.

[0003] Current vehicle status transmission mainly relies on traditional light signals such as turn signals and brake lights. These signals can only provide a single status indication and cannot accurately and comprehensively convey detailed information about the vehicle's driving status. In complex road conditions, insufficient information transmission can easily lead to collision risks and fail to meet the needs of efficient coordination between vehicles. In addition, existing lighting control methods do not fully integrate multi-source data such as the status of surrounding vehicles and environmental information. In complex road conditions, the adjustment of lighting areas lacks flexibility and specificity, and cannot effectively cope with the differentiated light coverage requirements of different road conditions, making it difficult to improve the practicality and adaptability of lighting systems in complex scenarios. Summary of the Invention

[0004] This invention addresses the technical problems existing in the prior art by providing a distributed matrix vehicle lighting intelligent control system.

[0005] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A distributed matrix vehicle lighting intelligent control system, comprising:

[0006] Driving data encoding module: acquires the driving status information of the vehicle and generates a first status code based on the driving status information;

[0007] Encoded light field projection control module: controls the vehicle's matrix headlights to project a first encoded light field carrying the first state code onto the area in front of the vehicle;

[0008] Incident light sensing and second state encoding and decoding module: senses incident light from the front and surrounding areas of the vehicle, extracts the second encoded light field projected by the matrix headlights of other vehicles from the incident light, and obtains at least one second state code based on the second encoded light field decoding;

[0009] Local light field negotiation process execution module: Based on the first state code and the second state code, execute a local light field negotiation process once to determine a description of the vehicle's expected lighting area that should be preferentially covered by the vehicle's light;

[0010] The local light field negotiation process includes: receiving and verifying the first and second state codes from the incident light sensing and second state encoding / decoding module; simultaneously extracting the vehicle's current driving environment parameters and matrix headlight hardware parameters; and loading a preset local light field negotiation rule base, which contains the core negotiation logic.

[0011] Rule 1: When the vehicle is traveling in the same direction as surrounding vehicles, priority should be given to covering the core area of ​​the vehicle's travel path;

[0012] Rule 2: When the vehicle is braking, priority should be given to covering the safety warning area ahead;

[0013] Rule 3: When surrounding vehicles are turning, this vehicle must avoid the area covered by their light field;

[0014] Rule 4: When the ambient light intensity is low, prioritize covering the area in front of the light source;

[0015] Cooperative beam pattern synthesis and control module: Based on the description of the expected lighting area of ​​this vehicle, it controls each light-emitting unit of the matrix headlights of this vehicle to synthesize a cooperative beam pattern that matches the description of the expected lighting area;

[0016] In the local light field negotiation process execution module, weights are assigned to each negotiation rule, and the weights are dynamically adjusted in combination with the current driving state of the vehicle. The state of the vehicle is cross-compared with the state of surrounding vehicles to identify potential light field conflict points and mark the conflict level. Based on the negotiation rule and state comparison results, multiple candidate schemes for the expected lighting area of ​​the vehicle are generated. Each scheme includes the area range and light intensity level, and the applicable scenarios of each scheme are determined.

[0017] Feasibility assessments are conducted for each candidate area scheme, with assessment dimensions including: light field coverage accuracy, compatibility with the light fields of surrounding vehicles, hardware feasibility, and environmental adaptability. A weighted scoring method is used to score each candidate scheme, and the scheme with the highest score is selected as the core content of the vehicle's expected lighting area description. If multiple schemes with similar scores exist, further filtering is performed using global instructions from the system's main controller. The optimal area scheme is then transformed into a standardized description of the vehicle's expected lighting area, with the following format:

[0018] Area scope: Define the coverage distance ahead;

[0019] Light field parameters: light intensity level;

[0020] Priority: Identify the area where the vehicle is expected to receive illumination as the priority coverage area;

[0021] The system outputs the description of the vehicle's intended lighting area to the collaborative beam pattern synthesis and control module, and simultaneously feeds back the negotiation results to the system's main controller. If a high conflict occurs during the negotiation process, an emergency lighting adjustment command is triggered to ensure driving safety.

[0022] In a preferred embodiment, the driving data encoding module invokes onboard multi-source sensors, including a GPS positioning unit, an inertial measurement unit, a vehicle speed sensor, a steering angle sensor, a braking sensor, and an acceleration sensor. The module determines the acquisition frequency of each sensor and collects raw data, specifically as follows:

[0023] The vehicle's real-time location, direction of travel, and altitude are obtained from the GPS positioning unit.

[0024] Information on the vehicle's current speed, acceleration, and deceleration is obtained from the vehicle speed sensor;

[0025] Information on the vehicle's steering angle and steering rate is obtained from the steering angle sensor;

[0026] Information on the vehicle's braking status and braking intensity is obtained from the braking sensors;

[0027] Obtain vehicle attitude information from the IMU;

[0028] The collected raw data is filtered using Kalman filtering and median filtering to remove sensor noise, eliminate and correct abnormal data, and convert the preprocessed raw data into a unified structured data format. A timestamp is added to each data point, and encoding rules are established. Based on binary, a fixed segment structure with functional segments and check bits is adopted to adapt to the vehicle scenario. The total length is determined according to the number and value range of core driving parameters, with reserved extension bits. The core state parameters of vehicle speed and direction are mapped to corresponding encoded values ​​according to their values. The encoding rules include encoding format, encoding length, and encoding mapping relationship. Core driving state parameters are extracted from the standardized structured data. According to the encoding rules, the extracted state parameters are mapped to corresponding encoded values. The mapped encoded values ​​are combined according to the encoding format to form a complete first state code. The generated first state code is verified by calculating the check bit of the code and comparing it with the check bit of the encoding. If they match, the verification passes; otherwise, the code is regenerated.

[0029] The core driving state parameters are extracted from the standardized structured data. Specifically, a core parameter extraction list is predefined, and vehicle speed and driving direction are identified as the target parameters to be extracted. The data is adapted to the coding rules, and the standardized structured data is traversed. The list fields are precisely matched to extract the valid parameter values ​​of the corresponding fields. The extracted parameters are verified for compliance, and invalid values ​​that do not conform to the preset value range are removed. After the verification is passed, a core driving state parameter set is formed.

[0030] The check bit is compared with the check bit of the code. Specifically, the fixed bit value of the preset check bit segment in the first state code is extracted and used as the check bit of the code to be compared. According to the established verification rules, the verification results of all functional segment code values ​​except the check bit in the code are recalculated to generate a new check bit. The newly calculated check bit is compared bit by bit with the check bit of the code. If the two check bits are completely the same, the comparison is deemed to pass and the code is valid. If there is a difference in bit value, the comparison is deemed to fail and the code is invalid.

[0031] In a preferred embodiment, the encoded light field projection control module establishes a real-time data communication link with the driving data encoding module, synchronously receives the first state code output by the module, verifies the validity of the received encoded data, including verifying the timeliness of the timestamp, the matching of the encoding format, and the integrity of the data, parses the verified first state code, extracts the core encoding information, converts it into basic light field control instructions that the matrix headlights can recognize, temporarily stores it in the module cache area, calls the hardware configuration parameters of the vehicle's matrix headlights, including the basic parameters of the number of light-emitting units, the unit light-emitting angle, the light intensity adjustment range, the unit arrangement coordinates, and the optical projection focal length, and collects the vehicle's current environment and driving-related parameters in real time, including the current vehicle speed, driving direction, ambient light intensity, and road lane width, to complete the environmental adaptation calibration of the light field projection.

[0032] Extracting core coding information specifically involves: based on the preset coding function segment division rules, locating the core function segment positions of vehicle speed and driving direction in the first state coding; extracting the coding values ​​of the core function segments of vehicle speed and driving direction in the first state coding from the verified binary coding; removing irrelevant segment data of extension bits and check bits; verifying the compliance of the extracted core coding values ​​to ensure that the core coding is within the preset value range, thus forming a core coding information set to be converted.

[0033] The process involves converting the extracted core encoded information set into corresponding control element values ​​according to the mapping table rules, integrating them into a standardized instruction framework, adapting the instruction framework to the format, and converting it into basic light field control instructions that the matrix headlight drive unit can directly parse. These instructions are then temporarily stored in the module cache area.

[0034] Based on a preset encoding and light field mapping protocol, the parsed basic light field control commands are mapped into independent operating parameters for each light-emitting unit of the matrix headlights. The core mapping rules include:

[0035] Brightness-off mapping: Specific coding bits correspond to the bright and dark states of specific light-emitting units, forming a basic coded light pattern;

[0036] Light intensity mapping: The level of the encoded value corresponds to the light intensity level of the light-emitting unit;

[0037] According to the driving communication protocol of the matrix headlights, the calibrated working parameters of each light-emitting unit are integrated into a standardized headlight hardware control instruction set. Execution identifiers and check codes are added to the control instruction set to ensure that there are no errors or losses when the instructions are transmitted to the headlight driving unit. The control instruction set is pre-loaded and verified to simulate the execution logic of the headlight driving unit and confirm the matching of the light field pattern with the first state code. The verified control instruction set is sent to the matrix headlight driving unit in real time through the vehicle bus to trigger each light-emitting unit to work collaboratively according to preset parameters. The headlight execution status is fed back in real time, and the operation of each light-emitting unit is monitored to ensure that it is consistent with the instructions. If a unit failure occurs, the fault tolerance mechanism is immediately activated: by adjusting the parameters of the surrounding normal units, the coded light field pattern is completed to ensure that the coded information is fully carried. The matrix headlights are controlled to project the first coded light field to the designated area in front of the vehicle and maintain the continuity of the light field projection until the first coded update instruction is received.

[0038] A real-time monitoring link for light field projection is established. The actual projection parameters of the light field are continuously collected through feedback data from the vehicle headlight drive unit. If an abnormality occurs in the light field projection, a fault alarm signal is immediately sent to the system main controller, and the fault information is recorded.

[0039] In a preferred embodiment, the incident light sensing and second-state encoding / decoding module calls the photosensitive sensing unit integrated in the matrix headlights to collect raw incident light data in real time from the area in front of and around the vehicle, including key parameters such as light intensity, light angle, light frequency, light distribution pattern, and spectral characteristics. The acquisition frequency is synchronized with the onboard sensor. Kalman filtering and median filtering algorithms are used to remove noise data mixed in during sensor acquisition. Through a preset background light calibration algorithm, the ambient background light intensity is calculated and subtracted to separate the target light field signal and the background light signal. The preprocessed raw light data is then processed. The data is converted into a unified structured data format, and a pre-defined coded light field feature library is established to store the standard features of the coded light fields projected by the matrix headlights of other vehicles. The pre-processed incident light data is compared with the standard features in the feature library. Through feature matching algorithms, the target light field signal that conforms to the coded light field features is identified, and interference signals from natural light, streetlights, and other stray light are eliminated. The boundary of the identified second coded light field is located to determine its projection range, coverage angle, and light intensity distribution area. The core parameters of the second coded light field are extracted, including the coded format identifier of the light field, the emission source position of the coded light field, and the projection direction of the coded light field.

[0040] Establish a pre-defined coded light field feature library, specifically by collecting unique features of light intensity, distribution, frequency, and spectrum of coded light fields from different vehicles to form a sample library. Quantify the features into comparable values ​​and unify the format. Store them according to encoding format and vehicle light type, and associate matching rules with decoding indexes.

[0041] The preprocessed incident light data is compared with the standard features in the feature library. Specifically, the intensity, distribution pattern, frequency and spectrum of the light are extracted from the preprocessed structured light data. The feature set to be matched is kept consistent with the standard feature dimension in the feature library. According to the preset weight, the feature to be matched is compared with the standard features in the feature library one by one in terms of dimensionality and numerical value. The feature matching degree is calculated. If the matching degree reaches the preset threshold, the match is determined to be successful and identified as the target coded light field. Otherwise, it is determined to be stray light and excluded.

[0042] The decoding rule base corresponding to the reverse of the first state encoding is called to extract the core parameters of the second encoded light field, match the corresponding decoding algorithm, analyze the light intensity change sequence and light point arrangement pattern of the second encoded light field, convert the light field signal into the corresponding encoded data, and map the parsed encoded data into specific driving state information according to the decoding rules, including the core parameters of other vehicles' speed, driving direction, braking status and steering angle. The validity of the decoded second state encoding is verified, and the verified second state encoding is output to the local light field negotiation process execution module.

[0043] The core parameters of the second coded light field are extracted as follows: from the structured data of the identified and located second coded light field, the core feature parameters of the light field signal are extracted according to the preset dimensions, including the time sequence of light intensity changes, the arrangement mode of the light spot matrix, the encoding format identifier, and parameters that are strongly correlated with the light field modulation frequency and decoding. Redundant data at the light field boundary and invalid data with weak light intensity fluctuations are removed, and the core parameters within the effective signal range are retained. The extracted parameters are standardized and normalized to unify the data format and value range, forming a set of core parameters of the second coded light field that can be directly input into the decoding algorithm.

[0044] In a preferred embodiment, the collaborative beam pattern synthesis and control module establishes a real-time data communication link with the local light field negotiation process execution module, receives the expected illumination area description of the vehicle, verifies its completeness and validity, verifies the timeliness of the area description, discards outdated description data, ensures matching with the current vehicle driving state and environmental parameters, and extracts core control parameters from the expected illumination area description, including:

[0045] Area range: forward coverage distance;

[0046] Light field parameters: light intensity level, beam shape, and projection direction;

[0047] The extracted parameters are converted into standardized control parameters that can be recognized by the matrix headlights;

[0048] The system calls upon the hardware configuration parameters of the vehicle's matrix headlights, including the number of light-emitting units, unit arrangement coordinates, optical projection focal length, and maximum light intensity of the light-emitting units, as the hardware basis for beam synthesis. It also collects current environmental and driving-related parameters in real time, including ambient light intensity, the vehicle's current speed, driving direction, road slope, and visibility. Based on the environmental parameters, it adjusts the light field parameters of the expected illumination area. When the ambient light intensity is low, it increases the beam intensity. When the vehicle is traveling at high speed, it expands the forward coverage distance. Based on the range of the expected illumination area and the beam shape, the light-emitting units of the matrix headlights are divided into multiple control groups.

[0049] Based on a preset unit and beam mapping protocol, standardized control parameters are mapped to the operating parameters of each unit group:

[0050] The central focusing group is responsible for covering the core area. The control unit illuminates the area with high brightness and at a small angle to create a focused light effect.

[0051] Edge Extension Group: Responsible for covering the edge areas of the region. The control unit illuminates the area with medium brightness and at a wide angle to create an extension effect.

[0052] Alternate Zone: Responsible for the avoidance area, the control unit is kept in low brightness and off state to avoid light interference;

[0053] The beams of each unit group are superimposed and calculated to simulate the actual effect after beam projection, ensuring that the synthesized collaborative beam pattern is completely matched with the expected illumination area. If a unit group fails, the parameters of other unit groups are automatically adjusted to complete the beam pattern. According to the matrix headlight drive communication protocol, the working parameters of each unit group are integrated into a standardized headlight hardware control instruction set. An execution identifier and check code are added to the instruction set. The verified control instruction set is sent to the matrix headlight drive unit in real time through the vehicle bus, triggering each light-emitting unit to work collaboratively according to preset parameters. The collaborative beam pattern synthesis and control module monitors the headlight execution status in real time to ensure that the working parameters of each unit group are consistent with the instructions. If a unit fails, the fault tolerance mechanism is immediately activated to adjust the parameters of surrounding units to complete the beam pattern. The matrix headlight controls the synthesized collaborative beam pattern to accurately project the beam pattern onto the expected illumination area of ​​the vehicle and maintain the projection continuity. Through the feedback data of the headlight drive unit, the actual parameters of the beam projection are continuously collected and compared with the expected parameters. If there is a beam pattern deviation, the unit group parameters are immediately adjusted to correct the beam pattern. If the beam projection is abnormal, a fault alarm signal is immediately sent to the system main controller and the fault information is recorded.

[0054] The actual effect after the simulated beam projection is as follows: retrieve the hardware parameters of the matrix headlight and the working parameters of each unit group, clarify the projection direction, coverage area and light intensity level of the single beam, and according to the unit group projection rules, superimpose the projection range and light intensity of the single beam group one by one to form the coverage area and light intensity distribution of the overall beam. Compare the superimposed overall beam information with the range and light intensity requirements of the expected lighting area dimension by dimension.

[0055] The comparison with the expected parameters is as follows: extract the core parameters of the expected lighting area, including coverage, light intensity distribution and shape boundary; extract the parameters of the actual projected beam, including light intensity distribution, coverage and shape boundary; compare the parameter differences between the two to see if the coverage matches, the light intensity distribution is consistent and the shape boundary matches; calculate the parameter deviation; if the deviation is within the preset threshold, it is determined to be a match; otherwise, the adjustment mechanism is activated.

[0056] In a preferred embodiment, the driving data encoding module converts the preprocessed raw data into a unified structured data format. Specifically, it defines a standardized structured data template with built-in fixed fields, including the vehicle's core driving state identifier, data acquisition source identifier, and reserved extended fields. It also presets the data type and value range constraints for each field. All preprocessed raw sensor data are traversed, and data is filled into the corresponding fields of the standardized structured data template according to the driving state type. Multi-source data for the same driving state are merged and filled according to preset rules. The filled fields are then normalized to unify heterogeneous data types from different sensors into system preset types, ensuring no difference in the formats of numerical, Boolean, and enumerated data. A millisecond-level timestamp is added to each filled structured data entry, with the timestamp consistent with the sensor's original data acquisition time, serving as a data timeliness identifier. The structured data that has completed field filling, type normalization, and timestamp addition is subjected to integrity verification, eliminating invalid data with missing fields or data not matching the corresponding fields. After successful verification, the final unified structured data is formed and stored in the module cache for subsequent encoding.

[0057] In a preferred embodiment, the encoded light field projection control module establishes a real-time data communication link with the driving data encoding module. Specifically, this involves: using a unified communication protocol between the encoded light field projection control module and the driving data encoding module, specifying the data transmission format, baud rate, and data frame identifier; pre-setting a retransmission mechanism; the encoded light field projection control module calling the vehicle-mounted hardware communication interface to complete interface hardware initialization, including configuring the interface working mode, binding a dedicated communication address, and enabling data reception interrupts; simultaneously, completing a physical layer handshake with the hardware interface of the driving data encoding module to confirm a normal interface connection and the absence of hardware faults; and the encoded light field projection control module sending a connection request frame to the driving data encoding module, the frame containing the encoded light field projection control module device identifier, communication protocol version, and target data type. The driving data encoding module receives and verifies the request. To verify the validity of the link, a connection establishment response frame is returned. After the encoded light field projection control module receives the response frame and verifies it, the link establishment is completed, and the module enters the data-ready reception state. After the link is established, the encoded light field projection control module and the driving data encoding module exchange heartbeat frames at a preset frequency to confirm the link connectivity. If no heartbeat frame is received for three consecutive times, the link is considered to be interrupted, and the re-establishment process is immediately triggered. At the same time, based on the unified clock synchronization source of the vehicle system, the timestamp synchronization between the encoded light field projection control module and the driving data encoding module is completed to ensure that the timeliness verification of the timestamp of the first state encoding is accurate. The encoded light field projection control module opens a dedicated ring-shaped receiving buffer locally and initializes the encoded data parsing channel to ensure that the received first state encoded data can be directly written into the buffer and trigger the subsequent validity verification process, realizing seamless connection of reception, buffering and verification.

[0058] In a preferred embodiment, the coded light field projection control module establishes a real-time monitoring link for light field projection. Specifically, the coded light field projection control module and the vehicle headlight drive unit use a unified vehicle bus communication protocol, assign a unique identifier to the light field monitoring feedback data, initialize a bidirectional communication hardware interface, complete the physical layer link connection, send parameter feedback configuration instructions to the vehicle headlight drive unit, agree on the actual projection parameters of the light field, the feedback cycle and data format of the drive unit's working status, set trigger rules for the drive unit to actively transmit feedback data, open a dedicated buffer area for light field monitoring data within the coded light field projection control module, establish a real-time reception and parsing channel for feedback data, associate the logical link between light field parameter acquisition and anomaly judgment, build a fault alarm signal transmission channel from the coded light field projection control module to the system main controller, configure local recording rules for fault information, and complete the entire monitoring link construction process.

[0059] In a preferred embodiment, the local light field negotiation process execution module performs a cross-comparison between the vehicle's state and the states of surrounding vehicles. Specifically, it extracts the core state parameters of the vehicle and surrounding vehicles, unifies them into a standardized data format, and includes parameters such as vehicle speed, driving direction, braking status, steering angle, relative position, distance from the vehicle, and current driving path to ensure that the basic data format for comparison is consistent. The vehicle's state parameters are matched with the surrounding vehicle's state parameters according to preset comparison dimensions, specifically including: direction dimension, speed dimension, braking dimension, and position dimension.

[0060] Directional dimension: Compare the angle between the direction of travel of this vehicle and the direction of travel of surrounding vehicles to determine whether they are in the same direction or intersecting.

[0061] Speed ​​dimension: Compare the speed difference between this vehicle and surrounding vehicles to determine if there is a speed conflict;

[0062] Braking dimension: Compare the braking status of this vehicle with that of surrounding vehicles to determine whether there is a conflict in braking timing;

[0063] Position dimension: Compare the relative position and distance between this vehicle and surrounding vehicles to determine whether there is an overlap in the light field coverage area;

[0064] Based on the dimensionality comparison results, potential light field conflict points are identified, specifically:

[0065] If this vehicle is going straight and surrounding vehicles are turning left, and the distance between the two is less than a preset threshold, it is judged as a medium-level conflict.

[0066] If the vehicle brakes and surrounding vehicles do not slow down, and the distance between them is less than a preset threshold, it is judged as a high-level conflict.

[0067] If the vehicle is traveling in the same direction as the surrounding vehicles and the distance between them is relatively far, it is judged as a low-level conflict.

[0068] Assign corresponding weight coefficients to different types of conflict points, and combine these with the conflict level to indicate the severity of the conflict.

[0069] The beneficial effects of this invention are as follows: A first state code is generated based on vehicle driving status information. A first coded light field carrying this code is projected using matrix headlights, enabling visual transmission of vehicle status. Precise transmission of vehicle status is achieved through the coded light field, avoiding insufficient information transmission due to the singularity of traditional light signals, reducing collision risks. Real-time perception of surrounding incident light is achieved. The second coded light field projected by other vehicles is analyzed and decoded to obtain the second state code, enabling bidirectional interaction across vehicle state information. By combining its own and surrounding vehicle state information, the lighting area is dynamically adjusted to cope with complex road conditions, improving the targeting and practicality of lighting. Based on the first and second state codes, local light field negotiation is performed to determine the vehicle's expected lighting area, achieving precise planning of light coverage and breaking the limitations of single-vehicle lighting control. Through the interaction and negotiation of multi-vehicle light fields, a foundation is provided for subsequent technologies such as autonomous driving and vehicle-to-everything (V2X) communication. According to the description of the expected lighting area, the matrix headlights control each emitting unit to synthesize a matching collaborative beam pattern, achieving intelligent collaborative vehicle lighting. The collaborative beam pattern is synthesized based on the negotiation results, avoiding light waste while ensuring lighting coverage in key areas, thus improving the driving experience. Attached Figure Description

[0070] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0072] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0073] In the description of this application, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0074] like Figure 1 This embodiment provides: a distributed matrix headlight intelligent control system, comprising:

[0075] Driving data encoding module: acquires the driving status information of the vehicle and generates a first status code based on the driving status information;

[0076] Encoded light field projection control module: controls the vehicle's matrix headlights to project a first encoded light field carrying the first state code onto the area in front of the vehicle;

[0077] Incident light sensing and second state encoding and decoding module: senses incident light from the front and surrounding areas of the vehicle, extracts the second encoded light field projected by the matrix headlights of other vehicles from the incident light, and obtains at least one second state code based on the second encoded light field decoding;

[0078] Local light field negotiation process execution module: Based on the first state code and the second state code, execute a local light field negotiation process once to determine a description of the vehicle's expected lighting area that should be preferentially covered by the vehicle's light;

[0079] The local light field negotiation process includes: receiving and verifying the first and second state codes from the incident light sensing and second state encoding / decoding module; simultaneously extracting the vehicle's current driving environment parameters and matrix headlight hardware parameters; and loading a preset local light field negotiation rule base, which contains the core negotiation logic.

[0080] Rule 1: When the vehicle is traveling in the same direction as surrounding vehicles, priority should be given to covering the core area of ​​the vehicle's travel path;

[0081] Rule 2: When the vehicle is braking, priority should be given to covering the safety warning area ahead;

[0082] Rule 3: When surrounding vehicles are turning, this vehicle must avoid the area covered by their light field;

[0083] Rule 4: When the ambient light intensity is low, prioritize covering the area in front of the light source;

[0084] Specifically, the system simultaneously extracts the vehicle's current driving environment parameters and matrix headlight hardware parameters. This involves directly reading the pre-recorded matrix headlight hardware parameters from the module's local fixed storage area. These parameters include the number of light-emitting units, light-emitting angle, light intensity adjustment range, unit arrangement coordinates, and optical projection focal length. Real-time data collection is not required. The system also links the vehicle's onboard sensors and driving system to simultaneously collect the vehicle's current driving environment parameters, including real-time dynamic parameters such as current vehicle speed, driving direction, ambient light intensity, road lane width, and distance to surrounding obstacles. The read fixed hardware parameters and collected real-time environmental parameters are then uniformly converted into a structured data format that the module can recognize. These parameters are then categorized and integrated according to hardware and environmental parameters to form a complete parameter set for subsequent loading into the negotiated rule base.

[0085] Cooperative beam pattern synthesis and control module: Based on the description of the expected lighting area of ​​this vehicle, it controls each light-emitting unit of the matrix headlights of this vehicle to synthesize a cooperative beam pattern that matches the description of the expected lighting area;

[0086] In the local light field negotiation process execution module, weights are assigned to each negotiation rule, and the weights are dynamically adjusted in combination with the current driving state of the vehicle. The state of the vehicle is cross-compared with the state of surrounding vehicles to identify potential light field conflict points and mark the conflict level. Based on the negotiation rule and state comparison results, multiple candidate schemes for the expected lighting area of ​​the vehicle are generated. Each scheme includes the area range and light intensity level, and the applicable scenarios of each scheme are determined.

[0087] This process involves generating multiple candidate lighting zones for the vehicle's intended illumination area. Specifically, it extracts the vehicle's current state parameters from the driving system, including speed, lane position, headlight activation mode, illumination angle, and light intensity level. Using an incident light sensing module, it acquires the headlight activation status, illumination range, light intensity level, relative position, and distance of surrounding vehicles. The vehicle's lighting parameters are then cross-compared with those of surrounding vehicles, with a focus on the following analysis:

[0088] Does the vehicle's lighting range cover the lighting area of ​​surrounding vehicles, and is there any overlap in light fields?

[0089] Will the brightness of this vehicle's lights cause glare to surrounding vehicles?

[0090] Does the direction of the lights from surrounding vehicles conflict with that of this vehicle?

[0091] Based on the comparison results, potential light field collision points are marked and classified according to the severity of the collision:

[0092] Low level: The light fields slightly overlap, posing no safety hazards, and only minor adjustments to the lighting angle are required;

[0093] Medium level: The light fields overlap significantly, which may interfere with surrounding vehicles. The light intensity needs to be adjusted.

[0094] High level: Severe conflict in the light field poses a safety hazard and requires immediate adjustment of lighting parameters;

[0095] The candidate lighting schemes for this vehicle are as follows: Candidate Scheme 1: Basic Safety Type, Candidate Scheme 2: Collaborative Compatibility Type, Candidate Scheme 3: Nighttime Enhancement Type, and Candidate Scheme 4: Emergency Avoidance Type.

[0096] Candidate Option 1: Basic Security Type

[0097] Area range: A rectangular area 100m in front of the vehicle and 30m to the left and right, with the light field covering the lane and the edges on both sides, without excessive extension;

[0098] Light intensity level: Low beam mode, light intensity level is 3;

[0099] Applicable scenarios: Urban roads and ordinary suburban roads, where there are no dense vehicles nearby and the distance between oncoming vehicles is >50m;

[0100] Candidate Solution 2: Collaborative Compatibility:

[0101] Area range: A rectangular area 50m in front of the vehicle and 20m to the left and right. The light field is focused on the vehicle's driving lane to reduce interference with surrounding vehicles.

[0102] Light intensity level: Low beam mode, light intensity level is 2;

[0103] Applicable scenarios: Congested urban roads, driving in close proximity to other vehicles, where there is a high density of surrounding traffic and light field overlap needs to be avoided;

[0104] Candidate Option 3: Nighttime Enhanced Version

[0105] Area range: A rectangular area 200m in front of the vehicle and 40m to the left and right, with the light field covering the lane and a 10m range on both sides, with no interference from oncoming vehicles;

[0106] Light intensity level: High beam mode, light intensity level is 4;

[0107] Applicable scenarios: Road sections without streetlights at night, rural roads, oncoming vehicle distance >100m, and no dense traffic in the surrounding area;

[0108] Candidate Option 4: Emergency Avoidance Type

[0109] Area range: A rectangular area 80m in front of the vehicle and 50m to the left and right, with the light field covering the lane and a 15m range on both sides, and the light intensity level is 3.

[0110] Light intensity level: Low beam mode, light intensity level is 3;

[0111] Applicable scenarios: When sudden road conditions require temporary adjustment of the lighting range to avoid disturbing surrounding vehicles;

[0112] Feasibility assessments are conducted for each candidate area scheme, with assessment dimensions including: light field coverage accuracy, compatibility with the light fields of surrounding vehicles, hardware feasibility, and environmental adaptability. A weighted scoring method is used to score each candidate scheme, and the scheme with the highest score is selected as the core content of the vehicle's expected lighting area description. If multiple schemes with similar scores exist, further filtering is performed using global instructions from the system's main controller. The optimal area scheme is then transformed into a standardized description of the vehicle's expected lighting area, with the following format:

[0113] Area scope: Define the coverage distance ahead;

[0114] Light field parameters: light intensity level;

[0115] Priority: Identify the area where the vehicle is expected to receive illumination as the priority coverage area;

[0116] The system outputs the description of the vehicle's intended lighting area to the collaborative beam pattern synthesis and control module, and simultaneously feeds back the negotiation results to the system's main controller. If a high conflict occurs during the negotiation process, an emergency lighting adjustment command is triggered to ensure driving safety.

[0117] The driving data encoding module calls upon onboard multi-source sensors, including: a GPS positioning unit, an inertial measurement unit, a vehicle speed sensor, a steering angle sensor, a braking sensor, and an acceleration sensor. It determines the acquisition frequency of each sensor and collects raw data, specifically:

[0118] The vehicle's real-time location, direction of travel, and altitude are obtained from the GPS positioning unit.

[0119] Information on the vehicle's current speed, acceleration, and deceleration is obtained from the vehicle speed sensor;

[0120] Information on the vehicle's steering angle and steering rate is obtained from the steering angle sensor;

[0121] Information on the vehicle's braking status and braking intensity is obtained from the braking sensors;

[0122] Obtain vehicle attitude information from the IMU;

[0123] The collected raw data is filtered using Kalman filtering and median filtering to remove sensor noise, eliminate and correct abnormal data, and convert the preprocessed raw data into a unified structured data format. A timestamp is added to each data point, and encoding rules are established. Based on binary, a fixed segment structure with functional segments and check bits is adopted to adapt to the vehicle scenario. The total length is determined according to the number and value range of core driving parameters, with reserved extension bits. The core state parameters of vehicle speed and direction are mapped to corresponding encoded values ​​according to their values. The encoding rules include encoding format, encoding length, and encoding mapping relationship. Core driving state parameters are extracted from the standardized structured data. According to the encoding rules, the extracted state parameters are mapped to corresponding encoded values. The mapped encoded values ​​are combined according to the encoding format to form a complete first state code. The generated first state code is verified by calculating the check bit of the code and comparing it with the check bit of the encoding. If they match, the verification passes; otherwise, the code is regenerated.

[0124] The core driving state parameters are extracted from the standardized structured data. Specifically, a core parameter extraction list is predefined, and vehicle speed and driving direction are identified as the target parameters to be extracted. The data is adapted to the coding rules, and the standardized structured data is traversed. The list fields are precisely matched to extract the valid parameter values ​​of the corresponding fields. The extracted parameters are verified for compliance, and invalid values ​​that do not conform to the preset value range are removed. After the verification is passed, a core driving state parameter set is formed.

[0125] The predefined core parameter extraction list is as follows: based on the type of parameter to be encoded determined by the encoding rules, vehicle speed and driving direction are locked as the core extraction objects. The exclusive field name and data type in the structured data of each core parameter are specified to form the extraction field identifier. The compliant value range of each parameter is defined as the basis for subsequent verification. The above information is integrated to form an extraction list and solidified.

[0126] The check bit is compared with the check bit of the code. Specifically, the fixed bit value of the preset check bit segment in the first state code is extracted and used as the check bit of the code to be compared. According to the established verification rules, the verification results of all functional segment code values ​​except the check bit in the code are recalculated to generate a new check bit. The newly calculated check bit is compared bit by bit with the check bit of the code. If the two check bits are completely the same, the comparison is deemed to pass and the code is valid. If there is a difference in bit value, the comparison is deemed to fail and the code is invalid.

[0127] In the coded light field projection control module, a real-time data communication link is established with the driving data encoding module. The first state code output by the module is received synchronously. The received encoded data is validated, including the validity of the timestamp, the matching of the encoding format, and the integrity of the data. The validated first state code is parsed, the core encoding information is extracted, and it is converted into basic light field control instructions that the matrix headlights can recognize. The instructions are temporarily stored in the module cache area. The hardware configuration parameters of the matrix headlights of the vehicle are called, including the basic parameters of the number of light-emitting units, the unit light-emitting angle, the light intensity adjustment range, the unit arrangement coordinates, and the optical projection focal length. The current environment and driving-related parameters of the vehicle are collected in real time, including the current vehicle speed, driving direction, ambient light intensity, and road lane width, to complete the environmental adaptation calibration of the light field projection.

[0128] Extracting core coding information specifically involves: based on the preset coding function segment division rules, locating the core function segment positions of vehicle speed and driving direction in the first state coding; extracting the coding values ​​of the core function segments of vehicle speed and driving direction in the first state coding from the verified binary coding; removing irrelevant segment data of extension bits and check bits; verifying the compliance of the extracted core coding values ​​to ensure that the core coding is within the preset value range, thus forming a core coding information set to be converted.

[0129] Specifically, based on the preset coding function segment division rules, the following steps are taken: according to the fixed segment structure of the coding design, independent core function segments are allocated for vehicle speed and driving direction, the start and end positions of each segment in binary encoding are clarified, a unique position range is defined, the position range of extension bits and check bits in non-core segments is defined, and they are clearly distinguished from core function segments to avoid truncation and confusion. The segment division and segment function correspondence are solidified to form a unified function segment identification rule, which is synchronized to the encoding and decoding modules to ensure that the rules at both ends are consistent.

[0130] The process involves converting the extracted core encoded information set into corresponding control element values ​​according to the mapping table rules, integrating them into a standardized instruction framework, adapting the instruction framework to the format, and converting it into basic light field control instructions that the matrix headlight drive unit can directly parse. These instructions are then temporarily stored in the module cache area.

[0131] Based on a preset encoding and light field mapping protocol, the parsed basic light field control commands are mapped into independent operating parameters for each light-emitting unit of the matrix headlights. The core mapping rules include:

[0132] Brightness-off mapping: Specific coding bits correspond to the bright and dark states of specific light-emitting units, forming a basic coded light pattern;

[0133] Light intensity mapping: The level of the encoded value corresponds to the light intensity level of the light-emitting unit;

[0134] According to the driving communication protocol of the matrix headlights, the calibrated working parameters of each light-emitting unit are integrated into a standardized headlight hardware control instruction set. Execution identifiers and check codes are added to the control instruction set to ensure that there are no errors or losses when the instructions are transmitted to the headlight driving unit. The control instruction set is pre-loaded and verified to simulate the execution logic of the headlight driving unit and confirm the matching of the light field pattern with the first state code. The verified control instruction set is sent to the matrix headlight driving unit in real time through the vehicle bus to trigger each light-emitting unit to work collaboratively according to preset parameters. The headlight execution status is fed back in real time, and the operation of each light-emitting unit is monitored to ensure that it is consistent with the instructions. If a unit failure occurs, the fault tolerance mechanism is immediately activated: by adjusting the parameters of the surrounding normal units, the coded light field pattern is completed to ensure that the coded information is fully carried. The matrix headlights are controlled to project the first coded light field to the designated area in front of the vehicle and maintain the continuity of the light field projection until the first coded update instruction is received.

[0135] Specifically, the standardized vehicle lighting hardware control instruction set is integrated as follows: the calibrated operating parameters of each light-emitting unit are converted into the standard data format defined by the matrix vehicle lighting drive communication protocol according to the field specifications, ensuring that the parameters correspond to the protocol fields; the standardized parameters of all light-emitting units are integrated according to the instruction frame structure required by the protocol, and execution identifiers and check codes are added to form a complete instruction set framework, ensuring the integrity and recognizability of the instructions; the execution logic of the vehicle lighting drive unit is simulated to verify the parameter matching and execution effect of the instruction set; the matching of the light field pattern and the first state code is confirmed; and after verification, it is solidified into a standardized instruction set that can be directly transmitted.

[0136] The execution logic of the simulated vehicle headlight drive unit is as follows: retrieve the instruction parsing rules and unit execution specifications of the matrix vehicle headlight drive unit, clarify the parsing order of the instruction set, the correspondence between parameters and unit actions, input the control instruction set to be verified, parse the instructions line by line according to the drive unit logic, map them to the actual execution actions of each light-emitting unit, restore the light field pattern of each unit working together according to the parsing results, compare the pattern with the light field pattern required by the first state encoding, and verify the matching.

[0137] A real-time monitoring link for light field projection is established. The actual projection parameters of the light field are continuously collected through feedback data from the vehicle headlight drive unit. If an abnormality occurs in the light field projection, a fault alarm signal is immediately sent to the system main controller, and the fault information is recorded.

[0138] The incident light sensing and second-state encoding / decoding module utilizes the integrated photosensitive unit of the matrix headlights to collect real-time raw data of incident light in front of and around the vehicle. This data includes key parameters such as light intensity, light angle, light frequency, light distribution pattern, and spectral characteristics. The acquisition frequency is synchronized with the onboard sensors. Kalman filtering and median filtering algorithms are used to remove noise data mixed in during sensor acquisition. A preset background light calibration algorithm is used to calculate and subtract the ambient background light intensity, separating the target light field signal from the background light signal. The preprocessed raw light data is then transformed into a unified... A structured data format is used to establish a pre-defined coded light field feature library, storing standard features of coded light fields projected by other vehicle matrix headlights. The pre-processed incident light data is compared with the standard features in the feature library. Through feature matching algorithms, target light field signals that conform to the coded light field features are identified, and interference signals from natural light, streetlights, and other stray light are eliminated. The boundary of the identified second coded light field is located to determine its projection range, coverage angle, and light intensity distribution area. The core parameters of the second coded light field are extracted, including the coded light field encoding format identifier, the emission source position of the coded light field, and the projection direction of the coded light field.

[0139] Among them, the Kalman filter and median filter algorithms are used. Specifically, the median filter is used for coarse processing: the original light data collected by the photosensitive unit is formed into a data sequence according to the collection time position, and the median of the sequence is used to replace the extreme value data of abnormal changes, so as to quickly remove the pulse noise and spike interference generated by the sensor collection and retain the overall trend of the data.

[0140] Post-Kalman filter optimization: The median-filtered light data is input into the filtering process. Based on the continuous change characteristics of light parameters, the light parameter values ​​at the next moment are predicted first. Then, the prediction deviation is corrected by combining the actual values ​​collected in real time. Random Gaussian noise in the data is dynamically removed to smooth the fluctuation of light parameters.

[0141] By integrating the results of the two filtering processes, we obtain the denoised clean light data, which provides an accurate data foundation for subsequent background light subtraction and target light field recognition.

[0142] The preset background light calibration algorithm is as follows: select a region without target light field from the filtered light data, extract the average light intensity of the region as the background light intensity benchmark, match the corresponding background light intensity compensation value for different positions according to the spatial distribution of the collection area, adapt to the regional differences of background light, and use the original light intensity data of each collection point to deduct the background light intensity value of the corresponding position point by point to separate the target light field signal and the background light signal.

[0143] Establish a pre-defined coded light field feature library, specifically by collecting unique features of light intensity, distribution, frequency, and spectrum of coded light fields from different vehicles to form a sample library. Quantify the features into comparable values ​​and unify the format. Store them according to encoding format and vehicle light type, and associate matching rules with decoding indexes.

[0144] The preprocessed incident light data is compared with the standard features in the feature library. Specifically, the intensity, distribution pattern, frequency and spectrum of the light are extracted from the preprocessed structured light data. The feature set to be matched is kept consistent with the standard feature dimension in the feature library. According to the preset weight, the feature to be matched is compared with the standard features in the feature library one by one in terms of dimensionality and numerical value. The feature matching degree is calculated. If the matching degree reaches the preset threshold, the match is determined to be successful and identified as the target coded light field. Otherwise, it is determined to be stray light and excluded.

[0145] The decoding rule base corresponding to the reverse of the first state encoding is called to extract the core parameters of the second encoded light field, match the corresponding decoding algorithm, analyze the light intensity change sequence and light point arrangement pattern of the second encoded light field, convert the light field signal into the corresponding encoded data, and map the parsed encoded data into specific driving state information according to the decoding rules, including the core parameters of other vehicles' speed, driving direction, braking status and steering angle. The validity of the decoded second state encoding is verified, and the verified second state encoding is output to the local light field negotiation process execution module.

[0146] The core parameters of the second coded light field are extracted as follows: from the structured data of the identified and located second coded light field, the core feature parameters of the light field signal are extracted according to the preset dimensions, including the time sequence of light intensity changes, the arrangement mode of the light spot matrix, the encoding format identifier, and parameters that are strongly correlated with the light field modulation frequency and decoding. Redundant data at the light field boundary and invalid data with weak light intensity fluctuations are removed, and the core parameters within the effective signal range are retained. The extracted parameters are standardized and normalized to unify the data format and value range, forming a set of core parameters of the second coded light field that can be directly input into the decoding algorithm.

[0147] In the collaborative beam pattern synthesis and control module, a real-time data communication link is established with the local light field negotiation process execution module. It receives the description of the vehicle's expected illumination area, verifies its completeness and validity, checks the timeliness of the area description, discards outdated description data, ensures it matches the current vehicle driving state and environmental parameters, and extracts core control parameters from the expected illumination area description, including:

[0148] Area range: forward coverage distance;

[0149] Light field parameters: light intensity level, beam shape, and projection direction;

[0150] The extracted parameters are converted into standardized control parameters that can be recognized by the matrix headlights;

[0151] Specifically, establishing a real-time data communication link with the local light field negotiation process execution module involves: following the vehicle bus communication specifications, defining a dedicated communication protocol between modules, clarifying the data transmission format, baud rate, verification method, and command interaction rules, configuring module communication interface parameters, building a bidirectional data transmission channel, binding a fixed communication address and data port to ensure directional data transmission, enabling real-time heartbeat detection and data retransmission mechanisms to ensure link connectivity and real-time data transmission, and establishing a stable real-time data communication link.

[0152] The system calls upon the hardware configuration parameters of the vehicle's matrix headlights, including the number of light-emitting units, unit arrangement coordinates, optical projection focal length, and maximum light intensity of the light-emitting units, as the hardware basis for beam synthesis. It also collects current environmental and driving-related parameters in real time, including ambient light intensity, the vehicle's current speed, driving direction, road slope, and visibility. Based on the environmental parameters, it adjusts the light field parameters of the expected illumination area. When the ambient light intensity is low, it increases the beam intensity. When the vehicle is traveling at high speed, it expands the forward coverage distance. Based on the range of the expected illumination area and the beam shape, the light-emitting units of the matrix headlights are divided into multiple control groups.

[0153] Based on a preset unit and beam mapping protocol, standardized control parameters are mapped to the operating parameters of each unit group:

[0154] The central focusing group is responsible for covering the core area. The control unit illuminates the area with high brightness and at a small angle to create a focused light effect.

[0155] Edge Extension Group: Responsible for covering the edge areas of the region. The control unit illuminates the area with medium brightness and at a wide angle to create an extension effect.

[0156] Alternate Zone: Responsible for the avoidance area, the control unit is kept in low brightness and off state to avoid light interference;

[0157] The beams of each unit group are superimposed and calculated to simulate the actual effect after beam projection, ensuring that the synthesized collaborative beam pattern is completely matched with the expected illumination area. If a unit group fails, the parameters of other unit groups are automatically adjusted to complete the beam pattern. According to the matrix headlight drive communication protocol, the working parameters of each unit group are integrated into a standardized headlight hardware control instruction set. An execution identifier and check code are added to the instruction set. The verified control instruction set is sent to the matrix headlight drive unit in real time through the vehicle bus, triggering each light-emitting unit to work collaboratively according to preset parameters. The collaborative beam pattern synthesis and control module monitors the headlight execution status in real time to ensure that the working parameters of each unit group are consistent with the instructions. If a unit fails, the fault tolerance mechanism is immediately activated to adjust the parameters of surrounding units to complete the beam pattern. The matrix headlight controls the synthesized collaborative beam pattern to accurately project the beam pattern onto the expected illumination area of ​​the vehicle and maintain the projection continuity. Through the feedback data of the headlight drive unit, the actual parameters of the beam projection are continuously collected and compared with the expected parameters. If there is a beam pattern deviation, the unit group parameters are immediately adjusted to correct the beam pattern. If the beam projection is abnormal, a fault alarm signal is immediately sent to the system main controller and the fault information is recorded.

[0158] Specifically, the beams of each unit group are superimposed and calculated. The core parameters of each light-emitting unit are extracted, including the emission angle, light intensity, color, projection range, and hardware layout of the matrix headlights. According to the driving communication protocol of the matrix headlights, the beams of each unit are superimposed and the light intensity is fused. The beam projection path, coverage area, and light intensity distribution of each unit are superimposed in three-dimensional space to generate a synthesized collaborative beam pattern. The superimposed beam pattern is compared with the expected illumination area to verify whether it is completely matched. If a deviation occurs, the adjustment mechanism is immediately triggered.

[0159] The actual effect after the simulated beam projection is as follows: retrieve the hardware parameters of the matrix headlight and the working parameters of each unit group, clarify the projection direction, coverage area and light intensity level of the single beam, and according to the unit group projection rules, superimpose the projection range and light intensity of the single beam group one by one to form the coverage area and light intensity distribution of the overall beam. Compare the superimposed overall beam information with the range and light intensity requirements of the expected lighting area dimension by dimension.

[0160] The comparison with the expected parameters is as follows: extract the core parameters of the expected lighting area, including coverage, light intensity distribution and shape boundary; extract the parameters of the actual projected beam, including light intensity distribution, coverage and shape boundary; compare the parameter differences between the two to see if the coverage matches, the light intensity distribution is consistent and the shape boundary matches; calculate the parameter deviation; if the deviation is within the preset threshold, it is determined to be a match; otherwise, the adjustment mechanism is activated.

[0161] In the driving data encoding module, the preprocessed raw data is converted into a unified structured data format. Specifically, a standardized structured data template is defined, with built-in fixed fields including the vehicle's core driving status identifier, data acquisition source identifier, and reserved extended fields. Data types and value range constraints for each field are preset. All preprocessed raw sensor data are traversed, and data is filled into the corresponding fields of the standardized structured data template according to the driving status type. Multi-source data for the same driving status are merged and filled according to preset rules. The data types of the filled fields are normalized, unifying heterogeneous data types from different sensors into system preset types, ensuring no difference in the formats of numerical, Boolean, and enumerated data. A millisecond-level timestamp is added to each filled structured data entry, with the timestamp consistent with the acquisition time of the original sensor data, serving as a data timeliness identifier. The structured data that has completed field filling, type normalization, and timestamp addition is subjected to integrity verification, eliminating invalid data with missing fields or data not matching the corresponding fields. After successful verification, the final unified structured data is formed and stored in the module cache for subsequent encoding.

[0162] In the encoded light field projection control module, a real-time data communication link is established with the driving data encoding module. Specifically, the encoded light field projection control module and the driving data encoding module use a unified communication protocol, agreeing on the data transmission format, transmission baud rate, and data frame identifier. A retransmission mechanism is also preset. The encoded light field projection control module calls the vehicle-mounted hardware communication interface to complete interface hardware initialization, including configuring the interface working mode, binding a dedicated communication address, and enabling data reception interrupts. Simultaneously, a physical layer handshake is completed with the hardware interface of the driving data encoding module to confirm a normal interface connection and the absence of hardware faults. The encoded light field projection control module sends a connection establishment request frame to the driving data encoding module. The frame contains the device identifier of the encoded light field projection control module, the communication protocol version, and the target data type. After receiving the frame, the driving data encoding module verifies the validity of the request and returns a response. Upon receiving the response frame, the coded light field projection control module receives and verifies the response frame, thus completing the link establishment and entering the data-ready receiving state. After link establishment, the coded light field projection control module and the driving data encoding module exchange heartbeat frames at a preset frequency to confirm link connectivity. If no heartbeat frame is received for three consecutive times, the link is considered interrupted, and the re-establishment process is immediately triggered. Simultaneously, based on the unified clock synchronization source of the vehicle system, the timestamp synchronization between the coded light field projection control module and the driving data encoding module is completed to ensure that the timeliness verification of the timestamp of the first state encoding is without deviation. The coded light field projection control module opens a dedicated ring-shaped receiving buffer locally and initializes the encoded data parsing channel to ensure that the received first state encoded data can be directly written into the buffer and trigger the subsequent validity verification process, achieving seamless connection between reception, buffering, and verification.

[0163] In the coded light field projection control module, a real-time monitoring link for light field projection is established. Specifically, the coded light field projection control module and the vehicle headlight drive unit use a unified vehicle bus communication protocol, assign a unique identifier to the light field monitoring feedback data, initialize the bidirectional communication hardware interface, complete the physical layer link connection, send parameter feedback configuration instructions to the vehicle headlight drive unit, agree on the feedback cycle and data format of the actual light field projection parameters and the working status of the drive unit, set the trigger rules for the drive unit to actively transmit feedback data, open a dedicated buffer area for light field monitoring data in the coded light field projection control module, establish a real-time reception and parsing channel for feedback data, associate the logical link between light field parameter acquisition and anomaly judgment, build a fault alarm signal transmission channel from the coded light field projection control module to the system main controller, configure local recording rules for fault information, and complete the entire monitoring link construction process.

[0164] In the local light field negotiation process execution module, the status of the vehicle is cross-compared with the status of surrounding vehicles. Specifically, the core status parameters of the vehicle and surrounding vehicles are extracted and standardized into a unified data format. The parameter types include vehicle speed, driving direction, braking status, steering angle, relative position, distance from the vehicle, and current driving path. This ensures that the basic data format for comparison is consistent. The status parameters of the vehicle are matched with the status parameters of surrounding vehicles according to preset comparison dimensions, specifically including: direction dimension, speed dimension, braking dimension, and position dimension.

[0165] Directional dimension: Compare the angle between the direction of travel of this vehicle and the direction of travel of surrounding vehicles to determine whether they are in the same direction or intersecting.

[0166] Speed ​​dimension: Compare the speed difference between this vehicle and surrounding vehicles to determine if there is a speed conflict;

[0167] Braking dimension: Compare the braking status of this vehicle with that of surrounding vehicles to determine whether there is a conflict in braking timing;

[0168] Position dimension: Compare the relative position and distance between this vehicle and surrounding vehicles to determine whether there is an overlap in the light field coverage area;

[0169] Specifically, the core state parameters of the vehicle and surrounding vehicles are extracted separately, namely: extraction of the state parameters of the vehicle and extraction of the state parameters of surrounding vehicles.

[0170] Vehicle status parameters extraction:

[0171] Vehicle speed: Collected in real time via onboard speed sensors, in km / h;

[0172] Driving direction: Based on the GPS positioning unit and inertial navigation system, output the current azimuth angle of the vehicle;

[0173] Braking status: The pressure value of the brake pedal and the on / off status of the brake lights are collected through the vehicle's brake sensors and ABS system.

[0174] Steering angle: Collected by the vehicle's steering system sensors, outputting the real-time rotation angle of the steering wheel;

[0175] Relative position: Calculate the vehicle's latitude and longitude coordinates in the road coordinate system using GPS positioning unit and vehicle map data;

[0176] Distance to this vehicle: The relative distance is calculated using spatial geometry by combining the positioning coordinates of this vehicle with those of surrounding vehicles.

[0177] Current driving route: Based on the in-vehicle navigation system, outputs the vehicle's currently planned driving route;

[0178] Extraction of surrounding vehicle status parameters:

[0179] Vehicle speed, driving direction, braking status, and steering angle: The vehicle's driving speed and steering direction are identified by the onboard camera, and the vehicle's braking status is detected by the radar sensor.

[0180] Relative position and distance from the vehicle: The positioning coordinates of surrounding vehicles are obtained through the GPS positioning unit and V2X communication module, and the relative position and distance are calculated by combining the positioning coordinates of the vehicle itself.

[0181] Current driving route: Receive navigation data from surrounding vehicles via V2X communication module, or identify the vehicle's driving trajectory via camera;

[0182] Based on the dimensionality comparison results, potential light field conflict points are identified, specifically:

[0183] If this vehicle is going straight and surrounding vehicles are turning left, and the distance between the two is less than a preset threshold, it is judged as a medium-level conflict.

[0184] If the vehicle brakes and surrounding vehicles do not slow down, and the distance between them is less than a preset threshold, it is judged as a high-level conflict.

[0185] If the vehicle is traveling in the same direction as the surrounding vehicles and the distance between them is relatively far, it is judged as a low-level conflict.

[0186] Assign corresponding weight coefficients to different types of conflict points, and combine these with the conflict level to indicate the severity of the conflict.

[0187] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0188] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0189] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0190] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0191] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0192] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0193] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A distributed matrix vehicle lighting intelligent control system, characterized in that, include: Driving data encoding module: acquires the driving status information of the vehicle and generates a first status code based on the driving status information; Encoded light field projection control module: controls the vehicle's matrix headlights to project a first encoded light field carrying the first state code onto the area in front of the vehicle; Incident light sensing and second state encoding and decoding module: senses incident light from the front and surrounding areas of the vehicle, extracts the second encoded light field projected by the matrix headlights of other vehicles from the incident light, and obtains at least one second state code based on the second encoded light field decoding; Local light field negotiation process execution module: Based on the first state code and the second state code, execute a local light field negotiation process once to determine a description of the vehicle's expected lighting area that should be preferentially covered by the vehicle's light; The local light field negotiation process includes: receiving and verifying the first and second state codes from the incident light sensing and second state encoding / decoding module; simultaneously extracting the vehicle's current driving environment parameters and matrix headlight hardware parameters; and loading a preset local light field negotiation rule base, which contains the core negotiation logic. Rule 1: When the vehicle is traveling in the same direction as surrounding vehicles, priority should be given to covering the core area of ​​the vehicle's travel path; Rule 2: When the vehicle is braking, priority should be given to covering the safety warning area ahead; Rule 3: When surrounding vehicles are turning, this vehicle must avoid the area covered by their light field; Rule 4: When the ambient light intensity is low, prioritize covering the area in front of the light source; Cooperative beam pattern synthesis and control module: Based on the description of the expected lighting area of ​​this vehicle, it controls each light-emitting unit of the matrix headlights of this vehicle to synthesize a cooperative beam pattern that matches the description of the expected lighting area; In the local light field negotiation process execution module, weights are assigned to each negotiation rule, and the weights are dynamically adjusted in combination with the current driving state of the vehicle. The state of the vehicle is cross-compared with the state of surrounding vehicles to identify potential light field conflict points and mark the conflict level. Based on the negotiation rule and state comparison results, multiple candidate schemes for the expected lighting area of ​​the vehicle are generated. Each scheme includes the area range and light intensity level, and the applicable scenarios of each scheme are determined. Feasibility assessments are conducted for each candidate area scheme, with assessment dimensions including: light field coverage accuracy, compatibility with the light fields of surrounding vehicles, hardware feasibility, and environmental adaptability. A weighted scoring method is used to score each candidate scheme, and the scheme with the highest score is selected as the core content of the vehicle's expected lighting area description. If multiple schemes with similar scores exist, further filtering is performed using global instructions from the system's main controller. The optimal area scheme is then transformed into a standardized description of the vehicle's expected lighting area, with the following format: Area scope: Define the coverage distance ahead; Light field parameters: light intensity level; Priority: Identify the area where the vehicle is expected to receive illumination as the priority coverage area; The system outputs the description of the vehicle's intended lighting area to the collaborative beam pattern synthesis and control module, and simultaneously feeds back the negotiation results to the system's main controller. If a high conflict occurs during the negotiation process, an emergency lighting adjustment command is triggered to ensure driving safety.

2. The distributed matrix vehicle lighting intelligent control system according to claim 1, characterized in that, The driving data encoding module calls upon onboard multi-source sensors, including: a GPS positioning unit, an inertial measurement unit, a vehicle speed sensor, a steering angle sensor, a braking sensor, and an acceleration sensor. It determines the acquisition frequency of each sensor and collects raw data, specifically: The vehicle's real-time location, direction of travel, and altitude are obtained from the GPS positioning unit. Information on the vehicle's current speed, acceleration, and deceleration is obtained from the vehicle speed sensor; Information on the vehicle's steering angle and steering rate is obtained from the steering angle sensor; Information on the vehicle's braking status and braking intensity is obtained from the braking sensors; Obtain vehicle attitude information from the IMU; The collected raw data is filtered using Kalman filtering and median filtering to remove sensor noise, eliminate and correct abnormal data, and convert the preprocessed raw data into a unified structured data format. A timestamp is added to each data point, and encoding rules are established. Based on binary, a fixed segment structure with functional segments and check bits is adopted to adapt to the vehicle scenario. The total length is determined according to the number and value range of core driving parameters, with reserved extension bits. The core state parameters of vehicle speed and direction are mapped to corresponding encoded values ​​according to their values. The encoding rules include encoding format, encoding length, and encoding mapping relationship. Core driving state parameters are extracted from the standardized structured data. According to the encoding rules, the extracted state parameters are mapped to corresponding encoded values. The mapped encoded values ​​are combined according to the encoding format to form a complete first state code. The generated first state code is verified by calculating the check bit of the code and comparing it with the check bit of the encoding. If they match, the verification passes; otherwise, the code is regenerated. The core driving state parameters are extracted from the standardized structured data. Specifically, a core parameter extraction list is predefined, and vehicle speed and driving direction are identified as the target parameters to be extracted. The data is adapted to the coding rules, and the standardized structured data is traversed. The list fields are precisely matched to extract the valid parameter values ​​of the corresponding fields. The extracted parameters are verified for compliance, and invalid values ​​that do not conform to the preset value range are removed. After the verification is passed, a core driving state parameter set is formed. The check bit is compared with the check bit of the code. Specifically, the fixed bit value of the preset check bit segment in the first state code is extracted and used as the check bit of the code to be compared. According to the established verification rules, the verification results of all functional segment code values ​​except the check bit in the code are recalculated to generate a new check bit. The newly calculated check bit is compared bit by bit with the check bit of the code. If the two check bits are completely the same, the comparison is deemed to pass and the code is valid. If there is a difference in bit value, the comparison is deemed to fail and the code is invalid.

3. The distributed matrix vehicle lighting intelligent control system according to claim 1, characterized in that, In the coded light field projection control module, a real-time data communication link is established with the driving data encoding module. The first state code output by the module is received synchronously. The received encoded data is validated, including the validity of the timestamp, the matching of the encoding format, and the integrity of the data. The validated first state code is parsed, the core encoding information is extracted, and it is converted into basic light field control instructions that the matrix headlights can recognize. The instructions are temporarily stored in the module cache area. The hardware configuration parameters of the matrix headlights of the vehicle are called, including the basic parameters of the number of light-emitting units, the unit light-emitting angle, the light intensity adjustment range, the unit arrangement coordinates, and the optical projection focal length. The current environment and driving-related parameters of the vehicle are collected in real time, including the current vehicle speed, driving direction, ambient light intensity, and road lane width, to complete the environmental adaptation calibration of the light field projection. Extracting core coding information specifically involves: based on the preset coding function segment division rules, locating the core function segment positions of vehicle speed and driving direction in the first state coding; extracting the coding values ​​of the core function segments of vehicle speed and driving direction in the first state coding from the verified binary coding; removing irrelevant segment data of extension bits and check bits; verifying the compliance of the extracted core coding values ​​to ensure that the core coding is within the preset value range, thus forming a core coding information set to be converted. The process involves converting the extracted core encoded information set into corresponding control element values ​​according to the mapping table rules, integrating them into a standardized instruction framework, adapting the instruction framework to the format, and converting it into basic light field control instructions that the matrix headlight drive unit can directly parse. These instructions are then temporarily stored in the module cache area. Based on a preset encoding and light field mapping protocol, the parsed basic light field control commands are mapped into independent operating parameters for each light-emitting unit of the matrix headlights. The core mapping rules include: Brightness-off mapping: Specific coding bits correspond to the bright and dark states of specific light-emitting units, forming a basic coded light pattern; Light intensity mapping: The level of the encoded value corresponds to the light intensity level of the light-emitting unit; According to the driving communication protocol of the matrix headlights, the calibrated working parameters of each light-emitting unit are integrated into a standardized headlight hardware control instruction set. Execution identifiers and check codes are added to the control instruction set to ensure that there are no errors or losses when the instructions are transmitted to the headlight driving unit. The control instruction set is pre-loaded and verified to simulate the execution logic of the headlight driving unit and confirm the matching of the light field pattern with the first state code. The verified control instruction set is sent to the matrix headlight driving unit in real time through the vehicle bus to trigger each light-emitting unit to work collaboratively according to preset parameters. The headlight execution status is fed back in real time, and the operation of each light-emitting unit is monitored to ensure that it is consistent with the instructions. If a unit failure occurs, the fault tolerance mechanism is immediately activated: by adjusting the parameters of the surrounding normal units, the coded light field pattern is completed to ensure that the coded information is fully carried. The matrix headlights are controlled to project the first coded light field to the designated area in front of the vehicle and maintain the continuity of the light field projection until the first coded update instruction is received. A real-time monitoring link for light field projection is established. The actual projection parameters of the light field are continuously collected through feedback data from the vehicle headlight drive unit. If an abnormality occurs in the light field projection, a fault alarm signal is immediately sent to the system main controller, and the fault information is recorded.

4. The distributed matrix vehicle lighting intelligent control system according to claim 1, characterized in that, The incident light sensing and second-state encoding / decoding module utilizes the integrated photosensitive unit of the matrix headlights to collect real-time raw data of incident light in front of and around the vehicle. This data includes key parameters such as light intensity, light angle, light frequency, light distribution pattern, and spectral characteristics. The acquisition frequency is synchronized with the onboard sensors. Kalman filtering and median filtering algorithms are used to remove noise data mixed in during sensor acquisition. A preset background light calibration algorithm is used to calculate and subtract the ambient background light intensity, separating the target light field signal from the background light signal. The preprocessed raw light data is then transformed into a unified... A structured data format is used to establish a pre-defined coded light field feature library, storing standard features of coded light fields projected by other vehicle matrix headlights. The pre-processed incident light data is compared with the standard features in the feature library. Through feature matching algorithms, target light field signals that conform to the coded light field features are identified, and interference signals from natural light, streetlights, and other stray light are eliminated. The boundary of the identified second coded light field is located to determine its projection range, coverage angle, and light intensity distribution area. The core parameters of the second coded light field are extracted, including the coded light field encoding format identifier, the emission source position of the coded light field, and the projection direction of the coded light field. Establish a pre-defined coded light field feature library, specifically by collecting unique features of light intensity, distribution, frequency, and spectrum of coded light fields from different vehicles to form a sample library. Quantify the features into comparable values ​​and unify the format. Store them according to encoding format and vehicle light type, and associate matching rules with decoding indexes. The preprocessed incident light data is compared with the standard features in the feature library. Specifically, the intensity, distribution pattern, frequency and spectrum of the light are extracted from the preprocessed structured light data. The feature set to be matched is kept consistent with the standard feature dimension in the feature library. According to the preset weight, the feature to be matched is compared with the standard features in the feature library one by one in terms of dimensionality and numerical value. The feature matching degree is calculated. If the matching degree reaches the preset threshold, the match is determined to be successful and identified as the target coded light field. Otherwise, it is determined to be stray light and excluded. The decoding rule base corresponding to the reverse of the first state encoding is called to extract the core parameters of the second encoded light field, match the corresponding decoding algorithm, analyze the light intensity change sequence and light point arrangement pattern of the second encoded light field, convert the light field signal into the corresponding encoded data, and map the parsed encoded data into specific driving state information according to the decoding rules, including the core parameters of other vehicles' speed, driving direction, braking status and steering angle. The validity of the decoded second state encoding is verified, and the verified second state encoding is output to the local light field negotiation process execution module. The core parameters of the second coded light field are extracted as follows: from the structured data of the identified and located second coded light field, the core feature parameters of the light field signal are extracted according to the preset dimensions, including the time sequence of light intensity changes, the arrangement mode of the light spot matrix, the encoding format identifier, and parameters that are strongly correlated with the light field modulation frequency and decoding. Redundant data at the light field boundary and invalid data with weak light intensity fluctuations are removed, and the core parameters within the effective signal range are retained. The extracted parameters are standardized and normalized to unify the data format and value range, forming a set of core parameters of the second coded light field that can be directly input into the decoding algorithm.

5. The distributed matrix vehicle lighting intelligent control system according to claim 1, characterized in that, In the collaborative beam pattern synthesis and control module, a real-time data communication link is established with the local light field negotiation process execution module. It receives the description of the vehicle's expected illumination area, verifies its completeness and validity, checks the timeliness of the area description, discards outdated description data, ensures it matches the current vehicle driving state and environmental parameters, and extracts core control parameters from the expected illumination area description, including: Area range: forward coverage distance; Light field parameters: light intensity level, beam shape, and projection direction; The extracted parameters are converted into standardized control parameters that can be recognized by the matrix headlights; The system calls upon the hardware configuration parameters of the vehicle's matrix headlights, including the number of light-emitting units, unit arrangement coordinates, optical projection focal length, and maximum light intensity of the light-emitting units, as the hardware basis for beam synthesis. It also collects current environmental and driving-related parameters in real time, including ambient light intensity, the vehicle's current speed, driving direction, road slope, and visibility. Based on the environmental parameters, it adjusts the light field parameters of the expected illumination area. When the ambient light intensity is low, it increases the beam intensity. When the vehicle is traveling at high speed, it expands the forward coverage distance. Based on the range of the expected illumination area and the beam shape, the light-emitting units of the matrix headlights are divided into multiple control groups. Based on a preset unit and beam mapping protocol, standardized control parameters are mapped to the operating parameters of each unit group: The central focusing group is responsible for covering the core area. The control unit illuminates the area with high brightness and at a small angle to create a focused light effect. Edge Extension Group: Responsible for covering the edge areas of the region. The control unit illuminates the area with medium brightness and at a wide angle to create an extension effect. Alternate Zone: Responsible for the avoidance area, the control unit is kept in low brightness and off state to avoid light interference; The beams of each unit group are superimposed and calculated to simulate the actual effect after beam projection, ensuring that the synthesized collaborative beam pattern is completely matched with the expected illumination area. If a unit group fails, the parameters of other unit groups are automatically adjusted to complete the beam pattern. According to the matrix headlight drive communication protocol, the working parameters of each unit group are integrated into a standardized headlight hardware control instruction set. An execution identifier and check code are added to the instruction set. The verified control instruction set is sent to the matrix headlight drive unit in real time through the vehicle bus, triggering each light-emitting unit to work collaboratively according to preset parameters. The collaborative beam pattern synthesis and control module monitors the headlight execution status in real time to ensure that the working parameters of each unit group are consistent with the instructions. If a unit fails, the fault tolerance mechanism is immediately activated to adjust the parameters of surrounding units to complete the beam pattern. The matrix headlight controls the synthesized collaborative beam pattern to accurately project the beam pattern onto the expected illumination area of ​​the vehicle and maintain the projection continuity. Through the feedback data of the headlight drive unit, the actual parameters of the beam projection are continuously collected and compared with the expected parameters. If there is a beam pattern deviation, the unit group parameters are immediately adjusted to correct the beam pattern. If the beam projection is abnormal, a fault alarm signal is immediately sent to the system main controller and the fault information is recorded. The actual effect after the simulated beam projection is as follows: retrieve the hardware parameters of the matrix headlight and the working parameters of each unit group, clarify the projection direction, coverage area and light intensity level of the single beam, and according to the unit group projection rules, superimpose the projection range and light intensity of the single beam group one by one to form the coverage area and light intensity distribution of the overall beam. Compare the superimposed overall beam information with the range and light intensity requirements of the expected lighting area dimension by dimension. The comparison with the expected parameters is as follows: extract the core parameters of the expected lighting area, including coverage, light intensity distribution and shape boundary; extract the parameters of the actual projected beam, including light intensity distribution, coverage and shape boundary; compare the parameter differences between the two to see if the coverage matches, the light intensity distribution is consistent and the shape boundary matches; calculate the parameter deviation; if the deviation is within the preset threshold, it is determined to be a match; otherwise, the adjustment mechanism is activated.

6. The distributed matrix vehicle lighting intelligent control system according to claim 2, characterized in that, In the driving data encoding module, the preprocessed raw data is converted into a unified structured data format. Specifically, a standardized structured data template is defined, with built-in fixed fields including the vehicle's core driving status identifier, data acquisition source identifier, and reserved extended fields. Data types and value range constraints for each field are preset. All preprocessed raw sensor data are traversed, and data is filled into the corresponding fields of the standardized structured data template according to the driving status type. Multi-source data for the same driving status are merged and filled according to preset rules. The data types of the filled fields are normalized, unifying heterogeneous data types from different sensors into system preset types, ensuring no difference in the formats of numerical, Boolean, and enumerated data. A millisecond-level timestamp is added to each filled structured data entry, with the timestamp consistent with the acquisition time of the original sensor data, serving as a data timeliness identifier. The structured data that has completed field filling, type normalization, and timestamp addition is subjected to integrity verification, eliminating invalid data with missing fields or data not matching the corresponding fields. After successful verification, the final unified structured data is formed and stored in the module cache for subsequent encoding.

7. The distributed matrix vehicle lighting intelligent control system according to claim 3, characterized in that, In the encoded light field projection control module, a real-time data communication link is established with the driving data encoding module. Specifically, the encoded light field projection control module and the driving data encoding module use a unified communication protocol, agreeing on the data transmission format, transmission baud rate, and data frame identifier. A retransmission mechanism is also preset. The encoded light field projection control module calls the vehicle-mounted hardware communication interface to complete interface hardware initialization, including configuring the interface working mode, binding a dedicated communication address, and enabling data reception interrupts. Simultaneously, a physical layer handshake is completed with the hardware interface of the driving data encoding module to confirm a normal interface connection and the absence of hardware faults. The encoded light field projection control module sends a connection establishment request frame to the driving data encoding module. The frame contains the device identifier of the encoded light field projection control module, the communication protocol version, and the target data type. After receiving the frame, the driving data encoding module verifies the validity of the request and returns a response. Upon receiving the response frame, the coded light field projection control module receives and verifies the response frame, thus completing the link establishment and entering the data-ready receiving state. After link establishment, the coded light field projection control module and the driving data encoding module exchange heartbeat frames at a preset frequency to confirm link connectivity. If no heartbeat frame is received for three consecutive times, the link is considered interrupted, and the re-establishment process is immediately triggered. Simultaneously, based on the unified clock synchronization source of the vehicle system, the timestamp synchronization between the coded light field projection control module and the driving data encoding module is completed to ensure that the timeliness verification of the timestamp of the first state encoding is without deviation. The coded light field projection control module opens a dedicated ring-shaped receiving buffer locally and initializes the encoded data parsing channel to ensure that the received first state encoded data can be directly written into the buffer and trigger the subsequent validity verification process, achieving seamless connection between reception, buffering, and verification.

8. The distributed matrix vehicle lighting intelligent control system according to claim 3, characterized in that, In the coded light field projection control module, a real-time monitoring link for light field projection is established. Specifically, the coded light field projection control module and the vehicle headlight drive unit use a unified vehicle bus communication protocol, assign a unique identifier to the light field monitoring feedback data, initialize the bidirectional communication hardware interface, complete the physical layer link connection, send parameter feedback configuration instructions to the vehicle headlight drive unit, agree on the feedback cycle and data format of the actual light field projection parameters and the working status of the drive unit, set the trigger rules for the drive unit to actively transmit feedback data, open a dedicated buffer area for light field monitoring data in the coded light field projection control module, establish a real-time reception and parsing channel for feedback data, associate the logical link between light field parameter acquisition and anomaly judgment, build a fault alarm signal transmission channel from the coded light field projection control module to the system main controller, configure local recording rules for fault information, and complete the entire monitoring link construction process.

9. A distributed matrix vehicle lighting intelligent control system according to claim 1, characterized in that, In the local light field negotiation process execution module, the status of the vehicle is cross-compared with the status of surrounding vehicles. Specifically, the core status parameters of the vehicle and surrounding vehicles are extracted and standardized into a unified data format. The parameter types include vehicle speed, driving direction, braking status, steering angle, relative position, distance from the vehicle, and current driving path. This ensures that the basic data format for comparison is consistent. The status parameters of the vehicle are matched with the status parameters of surrounding vehicles according to preset comparison dimensions, specifically including: direction dimension, speed dimension, braking dimension, and position dimension. Directional dimension: Compare the angle between the direction of travel of this vehicle and the direction of travel of surrounding vehicles to determine whether they are in the same direction or intersecting. Speed ​​dimension: Compare the speed difference between this vehicle and surrounding vehicles to determine if there is a speed conflict; Braking dimension: Compare the braking status of this vehicle with that of surrounding vehicles to determine whether there is a conflict in braking timing; Position dimension: Compare the relative position and distance between this vehicle and surrounding vehicles to determine whether there is an overlap in the light field coverage area; Based on the dimensionality comparison results, potential light field conflict points are identified, specifically: If this vehicle is going straight and surrounding vehicles are turning left, and the distance between the two is less than a preset threshold, it is judged as a medium-level conflict. If the vehicle brakes and surrounding vehicles do not slow down, and the distance between them is less than a preset threshold, it is judged as a high-level conflict. If the vehicle is traveling in the same direction as the surrounding vehicles and the distance between them is relatively far, it is judged as a low-level conflict. Assign corresponding weight coefficients to different types of conflict points, and combine these with the conflict level to indicate the severity of the conflict.

Images