Vehicle hazard warning light control method, device and storage medium

Abstract

The application provides a vehicle danger warning light control method, device and storage medium. Vehicle perception data of a vehicle surrounding environment is acquired, and a current driving scene is identified, so that the system can distinguish different driving environments, and then corresponding danger warning light activation conditions are matched according to the scene types, thereby avoiding the false triggering or response lag of the traditional fixed threshold triggering mechanism in complex scenes. Subsequently, a control instruction is generated when the vehicle perception data meets the dynamic activation condition, the adaptive and accurate activation of the danger warning light in the complex driving environment is realized, and the risk of secondary accidents is reduced.

Description

Technical Field

[0001] This application relates to the field of automotive control technology, and in particular to a method, device and storage medium for controlling vehicle hazard warning lights. Background Technology

[0002] Existing hazard warning light (such as hazard lights) control technologies typically employ fixed threshold triggering mechanisms or simple rule-based judgments based on a single sensor. For example, hazard lights are triggered when the vehicle's deceleration exceeds a preset value or when a rain sensor detects rainfall intensity exceeding a set threshold. However, different driving scenarios, such as high-speed heavy rain, tunnel exits, curves, and backlighting, significantly differ in the timing and conditions required for hazard light activation. The current use of uniform fixed thresholds or rules leads to delayed hazard light response in complex scenarios and may also result in false triggering, affecting the accuracy and reliability of vehicle safety warnings.

[0003] Therefore, there is an urgent need for an intelligent control method that coordinates the operation of the range extender and the energy feedback system to solve the above problems. Summary of the Invention

[0004] To overcome the problems existing in the related technologies, this application provides a method, device and storage medium for controlling vehicle hazard warning lights.

[0005] Firstly, a method for controlling vehicle hazard warning lights is provided, the method comprising: Acquire vehicle perception data, including at least the vehicle's surrounding environment, and identify the current driving scenario based on the vehicle perception data; Determine the hazard warning light activation conditions corresponding to the current driving scenario, wherein different driving scenarios correspond to different hazard warning light activation conditions; When the vehicle perception data meets the hazard warning light activation conditions, a control command for the hazard warning light is generated.

[0006] According to the vehicle hazard warning light control method provided in this application, determining the hazard warning light activation conditions corresponding to the current driving scenario includes: Determine the risk level parameters for the current driving scenario; When the risk level parameter is the first preset level, the activation threshold corresponding to the current driving scenario is read from the preset scenario mapping table as the activation condition of the hazard warning light. The scenario mapping table contains preset driving scenarios with mapping relationships and corresponding preset activation thresholds.

[0007] According to the vehicle hazard warning light control method provided in this application, after obtaining the hazard level of the current driving scenario, the method further includes: When the risk level parameter is the second preset level, the activation threshold is calculated in real time based on the three-dimensional dynamic scene model to generate the activation conditions for the hazard warning light. The three-dimensional dynamic scene model is a parameterized model of online reinforcement learning, which includes at least road feature dimension, meteorological condition dimension and vehicle state dimension, and is used to output the corresponding hazard warning light activation threshold based on the input vehicle perception data.

[0008] According to the vehicle hazard warning light control method provided in this application, the step of generating the control command for the hazard warning light includes: When the risk level parameter is at the first preset level, a control command to activate the hazard warning light is generated, and the manual shutdown command is disabled; and / or, When the risk level parameter is the second preset level, a control command to activate the hazard warning light is generated, and a human-machine interaction prompt that allows manual shutdown is output. If the driver status monitoring parameters are detected to be lower than a preset threshold after the control command is output, the hazard warning light is forcibly activated and the manual turn-off operation command is blocked.

[0009] According to a vehicle hazard warning light control method provided in this application, when the vehicle perception data meets the hazard warning light activation condition, a control command for the hazard warning light is generated, including: The vehicle positioning data is obtained from the vehicle perception data, which is obtained through multi-source fusion positioning. Obtain differential correction information broadcast in real time from the roadside unit, correct the vehicle positioning data according to the differential correction information, and output the target positioning data; Determine whether the target location data meets the geographical location threshold for triggering a hazard warning; If the conditions are met, the activation conditions for the hazard warning light are satisfied, and a control command for the hazard warning light is generated.

[0010] According to the vehicle hazard warning light control method provided in this application, the multi-source fusion positioning includes: When satellite signals for the vehicle are available, satellite positioning data and differential correction information are fused to obtain the vehicle positioning data; When satellite signals for the vehicle are unavailable, visual positioning data and inertial navigation positioning data are fused to obtain the vehicle positioning data.

[0011] According to the vehicle hazard warning light control method provided in this application, the step of identifying the current driving scenario based on the vehicle perception data includes: The vehicle perception data is fused to obtain fused perception data; The fused perception data is input into a preset three-dimensional dynamic scene model, and the current driving scene is output.

[0012] According to a vehicle hazard warning light control method provided in this application, the vehicle perception data is fused to obtain fused perception data, including: Feature extraction is performed on at least one of the vehicle perception data to obtain the scene features of the current driving scene; The weights of the vehicle perception data in different modalities are dynamically adjusted based on the scene characteristics. The vehicle perception data is weighted and fused with the corresponding adjusted weights to obtain the fused perception data.

[0013] According to the vehicle hazard warning light control method provided in this application, the method further includes: A time-series model is used to detect conflicts between vehicle perception data of different modalities. When a data conflict is detected, a Kalman filter is activated for correction. Feature extraction is performed on at least one corrected vehicle perception data to obtain the scene features of the current driving scenario.

[0014] According to a vehicle hazard warning light control method provided in this application, the vehicle terminal is equipped with a lightweight edge computing unit, the edge computing unit including an FPGA. Before extracting features from at least one of the vehicle perception data to obtain the scene features of the current driving scene, the method further includes: At least one of the vehicle perception data is preprocessed using hardware acceleration via FPGA. The preprocessed vehicle perception data is then used for feature extraction to obtain the scene features of the current driving scenario.

[0015] Secondly, a device is provided, comprising: The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements any of the vehicle hazard warning light control methods described above.

[0016] Thirdly, a computer-readable storage medium is provided, on which a vehicle hazard warning light control program is stored, wherein the vehicle hazard warning light control program, when executed, implements the steps of any of the vehicle hazard warning light control methods described above.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the vehicle hazard warning light control method as described in any of the above.

[0018] This application provides a method, device, and storage medium for controlling vehicle hazard warning lights, which has the following beneficial effects: By acquiring vehicle perception data of the surrounding environment and identifying the current driving scenario, the system can distinguish different driving environments and then match the corresponding hazard warning light activation conditions according to the scenario type. This avoids the false triggering or delayed response of traditional fixed threshold triggering mechanisms in complex scenarios. Subsequently, when the vehicle perception data meets the dynamic activation conditions, a control command is generated to achieve adaptive and precise activation of the hazard warning lights in complex driving environments, reducing the risk of secondary accidents.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 This is a schematic diagram of the architecture of a vehicle hazard warning light control system provided in an embodiment of this application; Figure 2 This is a minimum system circuit diagram of the FPGA provided in the embodiments of this application; Figure 3 This is a flowchart of the edge computing unit data processing provided in the embodiments of this application; Figure 4 This is a flowchart illustrating a vehicle hazard warning light control method provided in an embodiment of this application; Figure 5 This is a block diagram illustrating the principle of multimodal sensing fusion provided in the embodiments of this application; Figure 6 This is a flowchart of dynamic scene modeling and parameter self-learning provided in the embodiments of this application; Figure 7 This is a flowchart of the multi-source fusion positioning error compensation process provided in the embodiments of this application; Figure 8 This is a flowchart of the hierarchical human-machine decision-making logic provided in the embodiments of this application; Figure 9 This is a circuit diagram of a hazard warning light drive provided in an embodiment of this application; Figure 10 This is a full-link timing diagram of the emergency braking to hazard warning light activation provided in an embodiment of this application; Figure 11 This is a schematic block diagram of a vehicle hazard warning light control device according to an exemplary embodiment of this application. Detailed Implementation

[0022] The technical solutions in the embodiments (or "implementations") of this application will be clearly and completely described herein with reference to the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0023] If the embodiments of this application contain terms relating to directional indications or positional relationships (such as up, down, left, right, front, back, inside, outside, top, bottom, center, vertical, horizontal, longitudinal, transverse, length, width, counterclockwise, clockwise, axial, radial, circumferential, etc.), such terms are only used to explain the relative positional relationships and movement of the components in a specific posture (as shown in the attached figures); if the specific posture changes, the directional indications or positional relationships will also change accordingly. Furthermore, the terms "first" and "second" used in the embodiments of this application are only for descriptive convenience and should not be construed as indicating or implying relative importance.

[0024] This application provides a method, device, and storage medium for controlling vehicle hazard warning lights. The following detailed description, in conjunction with the accompanying drawings, illustrates this application. The features described in the embodiments and implementations can be combined with each other.

[0025] To address the aforementioned technical problems, this application provides a method for controlling vehicle hazard warning lights.

[0026] The system aims to accelerate response through edge computing, improve reliability through multimodal perception fusion, enhance adaptability through dynamic scene modeling, ensure accuracy through multi-source positioning, and resolve conflicts through hierarchical human-machine decision-making. It forms a closed-loop technology chain from perception, decision-making, execution, and interaction, and ultimately achieves fast, accurate, flexible, and safe hazard warning control in complex scenarios (rapid response, accurate perception, dynamic adaptation, and safe co-driving), providing a systematic solution to reduce the risk of secondary accidents.

[0027] This application provides an embodiment of the architecture of a vehicle hazard warning light control system, referring to... Figure 1 , Figure 1 This is a schematic diagram of the architecture of a vehicle hazard warning light control system provided in an embodiment of this application.

[0028] In some embodiments, the architecture of a vehicle hazard warning light control system includes a perception layer, an edge decision layer, and an execution interaction layer.

[0029] The perception layer integrates a sensor matrix that includes at least environmental and positioning sensors to acquire vehicle perception data. This vehicle perception data includes at least data on the vehicle's surrounding environment, vehicle positioning data, and vehicle status data. In some cases, if the hazard warning light control strategy needs to be adjusted based on the driver's state, sensors that monitor the driver's state are also required; that is, the sensor matrix also includes a driver state sensor. These sensors cover the full-dimensional data collection of weather, road conditions, vehicle status, and driver behavior.

[0030] As an example, environmental sensors include, but are not limited to, millimeter-wave radar, lidar, infrared cameras, and optical rain sensors. Rain sensors, such as optical rain sensors, are used to detect rainfall intensity, typically with an accuracy of ±0.2 mm / h. Millimeter-wave radar can penetrate water films and is used to detect the distance and relative speed of targets ahead; for example, according to tests, 77 GHz millimeter-wave radar can penetrate 8 mm of water film. Cameras, such as infrared cameras, are used to identify lane lines, traffic signs, and weather conditions; typically, their nighttime water fog penetration rate is >90%. Lidar is used to acquire point cloud data, with a point cloud density of 2 million points / second.

[0031] Positioning sensors include, but are not limited to, GPS and INS integrated navigation systems, inertial measurement units for acquiring vehicle acceleration and angular velocity, and global navigation satellite system receiver modules for acquiring vehicle position, etc.

[0032] Driver status sensors include, but are not limited to, eye trackers and facial expression recognition cameras.

[0033] The sensors in the perception layer periodically (e.g., at 100Hz) collect data, and then send the sensor data to the decision layer through a data interface.

[0034] The decision-making layer receives this sensor data to identify the current driving scenario and provides corresponding hazard warning light control strategies based on the current driving scenario.

[0035] As an example, the decision-making algorithm is deployed on one or more servers, which can be, but are not limited to, cloud servers or servers hosted on specific vehicles with computing power. When the server is a cloud server, the cloud can collect the operating parameter data of all vehicles to make the most comprehensive and accurate control of the vehicle's hazard warning lights.

[0036] To address the issue of long response delays in traditional three-level processing links consisting of sensors, domain controllers, and the cloud, which are caused by network transmission latency in hazard warning light automatic control systems, this application migrates the data processing of the decision-making layer from the cloud to the local machine, thereby eliminating network transmission latency.

[0037] As one embodiment, the vehicle-mounted terminal is deployed on a lightweight edge computing unit, which integrates an MCU. The MCU is used for task scheduling and logic control, and has a built-in eMMC to store scene model parameters, eliminating network transmission latency through time-triggered task scheduling.

[0038] As another embodiment, the edge computing unit integrates an FPGA and an MCU, with the FPGA used for real-time algorithm hardware acceleration.

[0039] As an example, the FPGA is responsible for the hardware acceleration of preprocessing algorithms (such as radar point cloud filtering and timestamp synchronization), and its minimum system circuitry is as follows: Figure 2 As shown, Figure 2 The circuit diagram for the minimum FPGA system is shown below. The edge computing unit FPGA acceleration module circuit includes at least the example modules and functions shown in Table 1 below.

[0040] Table 1: To address the response latency issue, this module compresses the traditional three-level processing chain into a single-level real-time processing architecture, from the sensor to the edge computing unit, and adopts a hybrid scheduling strategy of time-triggered and event-triggered processing to ensure the absolute real-time response of critical tasks (such as emergency braking detection).

[0041] Reference Figure 3 , Figure 3 This is a flowchart of the edge computing unit's data processing. Deployed sensors periodically collect data and send raw data (such as millimeter-wave radar point clouds and rain sensor voltage values) to the FPGA via SPI / CAN-FD interfaces. The FPGA performs preprocessing on the acquired vehicle perception data to accelerate processing. This preprocessing includes at least one of filtering, coordinate transformation, and timestamp alignment. The MCU, based on the preprocessed data, calls the scene model to perform current driving scene recognition and hazard warning light activation condition determination, and generates hazard warning light control commands.

[0042] In this process, time-triggered task scheduling and FPGA hardware are used to shorten response time. Specifically, FPGA hardware acceleration reduces response latency, and time-triggered task scheduling eliminates network transmission latency. Thus, the real-time decision engine based on edge computing effectively solves the problem of insufficient response timeliness.

[0043] Continue to refer to Figure 3After the decision-making layer generates a control command for the hazard warning lights, the execution interaction layer responds to the command to activate and deactivate the lights. In the execution interaction layer, the hazard warning lights are controlled by a dedicated driver circuit (supporting 5A instantaneous current), the HUD (Head-Up Display) synchronously outputs interactive information with the instrument panel, and the V2X module (supporting the 802.11p protocol) communicates in real-time with the roadside unit (RSU). Upon receiving the control command for the hazard warning lights, the execution interaction layer directly drives the execution circuit via GPIO to illuminate the lights, reducing response latency.

[0044] In this embodiment, a three-tiered architecture consisting of a multimodal perception layer, an edge decision layer, and an execution interaction layer is adopted. High reliability and scalability are achieved through hardware decoupling and software modular design.

[0045] Based on the aforementioned vehicle hazard warning light control system, this application provides an embodiment of a vehicle hazard warning light control method, referring to... Figure 4 , Figure 4 This is a flowchart illustrating a vehicle hazard warning light control method provided in an embodiment of this application.

[0046] The vehicle hazard warning light control method specifically includes the following steps 101 to 104: In step 101, vehicle perception data, including at least the vehicle's surrounding environment, is acquired, and the current driving scenario is identified based on the vehicle perception data.

[0047] The vehicle uses onboard sensors to collect real-time data on the vehicle's surrounding environment, vehicle status, location, and driver status. The sensor matrix includes, but is not limited to, rain sensors, millimeter-wave radar, infrared cameras, and lidar, covering comprehensive data collection on weather, road conditions, vehicle status, and driver behavior.

[0048] To improve response time, as an example, before executing step 101, at least one of the vehicle perception data is hardware-accelerated preprocessed using an FPGA. The preprocessed vehicle perception data is used for feature extraction to obtain the scene features of the current driving scenario.

[0049] A lightweight edge computing unit, comprising an FPGA and an MCU, is deployed in the vehicle terminal. The aforementioned sensors output raw data at a preset frequency. The edge computing unit receives raw data from multiple sources, including millimeter-wave radar, cameras, rain sensors, and inertial measurement units. The FPGA's real-time decision engine then performs preprocessing to accelerate the acquisition of vehicle perception data. Preprocessing includes at least one of filtering, coordinate transformation, and timestamp alignment. For example, based on the timestamps of each sensor, interpolation or delay compensation methods are used to unify all data to the same reference time. Another example is converting radar point clouds and visual target detection results to the vehicle coordinate system. Yet another example is image distortion correction. Subsequently, the MCU, based on the preprocessed sensor data, performs current driving scene recognition and hazard warning activation condition determination, and generates hazard warning control commands. This includes fusion processing of the preprocessed data.

[0050] Reference Figure 5 , Figure 5 This is a block diagram illustrating the principle of multimodal perception fusion. In the multimodal sensors, millimeter-wave radar outputs reflection intensity, infrared cameras output grayscale images, and lidar outputs point cloud density. The MCU preprocesses this data, such as converting rainfall data from a rain sensor to millimeters per hour, and performing target detection on the radar / camera / lidar sensors, such as detecting vehicles ahead, water films, and lane markings. Subsequently, the data is transmitted via a data interface to the scene recognition module in the decision layer, where the acquired vehicle perception data is fused to identify the vehicle's current driving scene.

[0051] To address the issue of high false alarm rates in single-sensor systems and obtain accurate sensing results, in some embodiments, step 101 includes steps a1 to a2: Step a1: Perform fusion processing on the vehicle perception data to obtain fused perception data.

[0052] The edge computing unit receives the processed sensor data. To address the unreliability of perception in complex scenarios and improve perception accuracy, step a1 further includes: extracting features from at least one of the vehicle perception data to obtain scene features of the current driving scenario; dynamically adjusting the weights of the vehicle perception data of different modalities based on the scene features; and performing weighted fusion processing on the vehicle perception data and the corresponding adjusted weights to obtain fused perception data.

[0053] Continue to refer to Figure 5The edge computing unit receives data output from various sensors and extracts parameters that characterize the current scene features using a scene classifier. These extracted scene features form a multi-dimensional sensor feature vector. For example, it can identify complex scene features such as "heavy rain + backlight" and "tunnel + glare." Subsequent sensor weight fusion and 3D dynamic modeling are based on these features to infer the final scene type or control strategy.

[0054] As an example, feature extraction methods vary depending on the sensor type: For cameras, image contrast, brightness histogram variance, and haze levels (using dark channel priors) are calculated as illumination and visibility features. For radar, changes in point cloud density and reflectance intensity are statistically analyzed as rainfall or occlusion features. For rain gauges, voltage values ​​are converted into rainfall values ​​(mm / h) and directly used as meteorological features. For lidar, point cloud echo intensity and the number of effective points are analyzed as visibility features.

[0055] Next, the weights of each sensor are dynamically adjusted according to the scenario. That is, a dynamic weight fusion strategy is adopted to adjust the confidence allocation weights of different sensors in the current environment.

[0056] As an example, the obtained scene feature vectors are input into a pre-trained weight allocation model, which can be implemented in the following way: Method 1: Rule-based lookup mapping. For example, when rainfall is greater than 10 mm / h, the radar weight is set to 0.7, the camera weight to 0.2, and the lidar weight to 0.1. Method 2 is based on a lightweight neural network, such as a fully connected network, which takes scene features as input and outputs normalized values ​​of the weights of each sensor.

[0057] The weighted distribution model outputs a set of weight coefficients, each corresponding to a different sensor mode, with the sum of all weight coefficients equal to 1. For example, in rainy conditions, the weight of the millimeter-wave radar is increased (e.g., from 30% to 70%), while the weight of the camera is decreased (e.g., to 20%); the opposite is true under normal lighting conditions.

[0058] It should be noted that the calculation of dynamic weight allocation is performed in the MCU or FPGA of the edge computing unit, and the update frequency is consistent with the sensor data frame rate.

[0059] Subsequently, the multimodal sensor data is fused to obtain fused perception data, which is then used to identify the current driving scenario. In this embodiment, the fusion method employs weighted averaging or Kalman filtering, and the output fused perception measurements include, but are not limited to: the distance and speed of the target ahead, lane line position, current rainfall (e.g., 12 mm / h), vehicle deceleration, and lateral acceleration.

[0060] This embodiment utilizes the differences between sensors in different driving scenarios to dynamically adjust the contribution of each sensor according to the current scene characteristics, thereby improving the accuracy of the fused perception data and thus affecting the reliability of subsequent scene recognition and decision-making.

[0061] To avoid data conflicts from multiple sensors, the system is also equipped with a self-calibration module. Step a1 further includes using a time-series model to detect conflicts between vehicle perception data of different modalities, and initiating Kalman filtering for correction when a data conflict is detected; and extracting features from at least one corrected vehicle perception data to obtain the scene features of the current driving scenario.

[0062] An LSTM network is used to detect sensor data conflicts in real time. When the deviation exceeds a set value (e.g., the deviation between optical sensor and millimeter-wave radar rainfall data > 15%), Kalman filter correction is triggered. The specific process is as follows: Step 1: Data conflict detection: This is achieved using LSTM. The LSTM training data includes tens of thousands of sensor anomaly samples from various scenarios such as rainstorms and tunnels.

[0063] Input: Preprocessed data from each sensor (rainfall voltage conversion mm / h, radar reflection intensity, camera grayscale value, lidar point cloud density).

[0064] Conflict determination: For example, if the rain sensor reading is greater than 15 mm / h and the infrared camera grayscale change rate is less than the set value, it indicates that the rainstorm caused the camera to malfunction, and is then marked as an optical sensor conflict.

[0065] Step 2: Dynamic weight adjustment (linked with conflict detection). See Table 2 below.

[0066] Table 2: Step 3: Kalman filter correction (input dynamic weight results) Equations of state: (Motion Model) Observation equation: In this embodiment, a dual closed-loop feedback is implemented. The inner loop updates the LSTM collision detection threshold in reverse order of the correction result. For example, if the error after correction is still >5%, the grayscale abrupt change threshold is automatically tightened to 10%. The outer loop triggers dynamic weight coefficient iteration based on the correction result. For example, in a rainstorm scenario, the radar weight is adjusted from 70% to 80%.

[0067] By employing the complete process described above—LSTM detection of data conflicts, dynamic weight adjustment, Kalman filter correction, and dual closed-loop feedback—the problems of high false alarm rates for single sensors and data conflicts for multiple sensors are resolved.

[0068] Step a2: Input the fused perception data into a preset three-dimensional dynamic scene model and output the current driving scene.

[0069] In this embodiment, the preset 3D dynamic scene model is a parametric model that has been trained offline and supports online updates. Its input is fused perception data, which includes at least the measured values ​​of road features (slope / curvature), weather conditions (rainfall / visibility), and vehicle status (speed / deceleration, etc.). The output is the category label of the current driving scene. The driving scene categories include at least: high-speed rainstorm scene, tunnel entrance / exit scene, curve scene, backlight / glare scene, and normal driving scene.

[0070] Reference Figure 6 , Figure 6 The flowchart for dynamic scene modeling and parameter self-learning is as follows: The inference process based on the 3D dynamic scene model is as follows: The fused perception data is used as the input feature vector and input into the 3D dynamic scene model. The model performs forward calculation based on the input features through a preset classification logic (such as support vector machine, random forest or lightweight neural network), and outputs the scene category with the highest probability as the recognition result of the current driving scene, which is then passed to the subsequent activation condition determination module.

[0071] In some embodiments, to address the problem of poor environmental adaptability, a three-dimensional scene model and an online reinforcement learning mechanism are constructed. That is, a three-dimensional dynamic scene model of road features, weather conditions, and vehicle status is constructed, and the model parameters are updated through online learning (reinforcement learning and real-time data feedback).

[0072] Specifically, the system is equipped with an online reinforcement learning module. This module constructs a state space and acquires scene models and historical data by collecting real-time sensor data and historical behavior data. With the reward objective of reducing false trigger rates and improving response accuracy, it dynamically optimizes control parameters (such as deceleration thresholds, wiper strategies, and tunnel pre-activation distances) based on reinforcement learning, outputting optimized control strategies and parameters. Furthermore, based on this strategy, differentiated parameter adjustments are made for different scenarios. Through a self-learning and real-time update mechanism for the parameters, the system ultimately outputs the optimal control parameters adapted to the current scenario.

[0073] This includes, but is not limited to, updating model parameters in real time through reinforcement learning, such as: adjusting hazard warning deceleration thresholds, optimizing wiper linkage strategies, and adjusting tunnel pre-activation distances. For example, in a high-speed rainstorm scenario, the hazard warning activation condition can be automatically adjusted from "deceleration > 0.4g" to "deceleration > 0.3g," and the wiper frequency can be increased by 50%, resolving the error problem of mismatch between the original wiper linkage scheme and vehicle speed.

[0074] For example, by pre-storing high-precision map tunnel coordinates (±0.5m accuracy) and combining them with a light sensor (response <50ms) to trigger a pre-activation strategy 50m before the exit, compensation for tunnel scenes can be achieved, significantly reducing the false trigger rate.

[0075] It should be noted that in this 3D dynamic scene model, the model parameters (such as the feature weights, decision tree splitting thresholds, or neural network weights corresponding to each scene) are pre-stored in the eMMC memory of the edge computing unit.

[0076] In step 102, the activation conditions for the hazard warning lights corresponding to the current driving scenario are determined, wherein different driving scenarios correspond to different activation conditions for the hazard warning lights.

[0077] The three-dimensional dynamic scene model is a parameterized model based on online reinforcement learning, which includes at least road feature dimensions, meteorological condition dimensions, and vehicle state dimensions. It is used to output the corresponding hazard warning light activation threshold based on the input vehicle perception data.

[0078] In other words, in the 3D dynamic scene model, scene recognition is linked to parameters, with different scenes corresponding to different activation conditions, specifically manifested as different combinations of trigger thresholds. That is, when a scene is recognized, the corresponding hazard warning light activation threshold is output as the hazard warning light activation condition. To improve the response time of special scenes, such as emergency braking in heavy rain, which requires rapid triggering, the activation condition determination process for different scenes has different methods. As an example, step 102 further includes steps b1 to b21 and / or steps b1 to b22: Step b1: Determine the risk level parameters of the current driving scenario.

[0079] After identifying the current driving scene, the system determines the risk level parameters of the scene based on the scene type and real-time vehicle status (including but not limited to vehicle speed, deceleration, visibility, rainfall, etc.). In this embodiment, the risk level is divided into at least two preset levels: a first preset level and a second preset level.

[0080] The first preset level does not refer to a specific fixed risk level, but is named to distinguish it from other risk levels, and will not be repeated hereafter in the embodiments of this application. The first preset level is a high-risk scenario, such as high-speed emergency braking, collision warning, etc., in which the hazard warning lights need to be activated immediately.

[0081] The second preset level does not refer to a specific fixed risk level, but is named to distinguish it from other risk levels, and will not be repeated in the following embodiments of this application. The second preset level is for low to medium risk scenarios, such as normal deceleration and rain / fog warnings, and can be flexibly handled according to the driver's condition.

[0082] The risk level parameter can be determined in the following two ways: Method 1: Determined based on a predefined mapping table. Each scenario type is directly associated with a default risk level. For example, the tunnel exit scenario defaults to the first preset level, and the rainy and slippery scenario defaults to the second preset level. Method 2: Rule-based determination. If the current deceleration is greater than 0.6g or the distance to the vehicle in front is less than the safety threshold, then the system will be upgraded to the first preset level.

[0083] Step b21: When the risk level parameter is the first preset level, the activation threshold corresponding to the current driving scenario is read from the preset scenario mapping table as the activation condition of the hazard warning light. The scenario mapping table contains preset driving scenarios with mapping relationships and corresponding preset activation thresholds.

[0084] If the risk level parameter is the first preset level, the activation threshold is directly read from the preset scene mapping table. This mapping table is stored in the memory of the edge computing unit, recording the preset activation thresholds corresponding to different scenarios in key-value pairs. For example, for an emergency braking scenario in heavy rain, a pre-cached mapping table of braking intensity and hazard warning light activation thresholds is used. If the deceleration is greater than 0.6g, the system will trigger immediately, achieving a trigger decision with zero computational latency. Following vehicles can perceive the dangerous state of the vehicle in front 600ms in advance, significantly reducing the risk of chain-reaction rear-end collisions in heavy rain.

[0085] The lookup table operation eliminates the need for complex calculations and has negligible latency, ensuring that hazard warning lights are triggered extremely quickly in high-risk scenarios.

[0086] Step b22: When the risk level parameter is the second preset level, the activation threshold is calculated in real time based on the three-dimensional dynamic scene model to generate the activation conditions for the hazard warning light.

[0087] If the risk level is the second preset level, the system invokes a 3D dynamic scene model and dynamically calculates the activation threshold based on the current real-time perception data. Details are as follows: The fused sensing data obtained through fusion processing is used as a feature vector input to the 3D dynamic scene model. Since the 3D dynamic scene model is a parameterized model that is continuously updated through online reinforcement learning, its internal structure can be a neural network, decision tree, or linear regression function. After inputting the feature vector, a set of activation thresholds is output, including but not limited to deceleration threshold, lateral acceleration threshold, and geographic location threshold.

[0088] For example, in mountainous bends and light rain scenarios, the model outputs a lateral acceleration threshold of 0.35g; in urban slippery road scenarios, it outputs a deceleration threshold of 0.4g.

[0089] For example, if the current scenario is a high-speed rainstorm scenario, the activation condition is set as follows: deceleration threshold > 0.3g, which is earlier than the 0.4g in the normal scenario, and rainfall threshold > 10mm / h as an auxiliary verification condition.

[0090] For example, by pre-storing the coordinates of tunnel entrances and exits in a high-precision map, and combining this with a light sensor (response time < 50ms) to detect sudden changes in light levels inside and outside the tunnel, a strategy can be implemented to trigger a pre-activated hazard warning 50m before the tunnel exit, thereby reducing the false trigger rate.

[0091] It should be noted that after each decision, the system records the triggering result, driver intervention behavior, and accident avoidance as feedback data, and uses reinforcement learning algorithms (such as Q-learning or policy gradient) to periodically update the model parameters so that the threshold gradually approaches the optimal value of the current driving environment.

[0092] Whether the activation threshold is obtained by looking up a table or the dynamic activation threshold is calculated in real time by the model, it is used as the activation condition for the hazard warning lights in the current driving scenario. The system continuously monitors vehicle perception data, and when the condition is met, it immediately generates a hazard warning control command.

[0093] In step 103, when the vehicle perception data meets the hazard warning light activation conditions, a control command for the hazard warning light is generated.

[0094] The system monitors vehicle perception data in real time and compares the current vehicle status parameters with the activation conditions determined for the current driving scenario. If all threshold conditions are met, the activation condition is determined to be met; if any threshold condition is not met, monitoring continues and activation is not triggered.

[0095] To improve the accuracy of vehicle positioning, step 103 further includes: acquiring vehicle positioning data from the vehicle perception data, wherein the vehicle positioning data is obtained through multi-source fusion positioning; acquiring differential correction information broadcast in real time by the roadside unit, and correcting the vehicle positioning data according to the differential correction information to output target positioning data; determining whether the target positioning data meets the geographical location threshold for triggering a hazard warning; if it does, then the hazard warning light activation condition is met, and a control command for the hazard warning light is generated.

[0096] Reference Figure 7 , Figure 7 This is a flowchart of the multi-source fusion positioning error compensation process. To address positioning deviation issues in special scenarios, a combination of multi-source fusion and V2X real-time differential correction is employed to ensure positioning accuracy in complex environments such as tunnels and curves.

[0097] In this embodiment, the positioning-related multi-source fusion sensors used may include GNSS (Global Navigation Satellite System), IMU (Inertial Measurement Unit), visual SLAM, and high-precision maps. GNSS is used to receive satellite signals and output the approximate latitude and longitude coordinates of the vehicle; IMU is used to output the vehicle's three-axis acceleration and angular velocity for short-term recursive position estimation; visual SLAM acquires road surface images through cameras, extracts features such as lane lines and roadside markings, matches them with pre-stored high-precision maps, and outputs the relative position; the high-precision map provides precise geometric information of the road (lane line coordinates, tunnel entrance and exit locations, etc.).

[0098] A multi-sensor fusion algorithm is used to complement and fuse the above positioning data, and output preliminary positioning results, namely vehicle positioning data.

[0099] As an example, the multi-source fusion positioning includes: when satellite signals for the vehicle are available, fusing satellite positioning data with differential correction information to obtain the vehicle positioning data; and when satellite signals for the vehicle are unavailable, fusing visual positioning data with inertial navigation positioning data to obtain the vehicle positioning data.

[0100] When GNSS signal is good, GNSS positioning is the primary method, and IMU short-time integration is used to compensate for the problems of low GNSS update frequency and susceptibility to obstruction. At the same time, visual SLAM matching results are used to constrain and correct GNSS.

[0101] When a vehicle enters a tunnel or curve and its GNSS signal is lost, the system switches to a combination of visual SLAM and IMU (Kalman filter to suppress cumulative error). Visual SLAM outputs the vehicle's pose relative to the map by comparing real-time images with high-precision map features, such as roadside signs and lane line feature matching. IMU provides high-frequency motion recursion. The two are fused through extended Kalman filter to suppress the cumulative drift of the IMU and output continuous and reliable positioning data.

[0102] The fused vehicle positioning data includes the vehicle's latitude and longitude coordinates, heading angle, speed, and estimated positioning quality. Subsequently, the vehicle receives real-time differential correction information broadcast by the roadside unit (RSU) via the V2X module. In this embodiment, differential correction information refers to error correction data calculated in real time by the precisely positioned roadside unit based on the deviation between its own GNSS observations and known true coordinates.

[0103] In this embodiment, differential correction information is broadcast in real time by the roadside unit. The vehicle positioning data is then corrected based on this information, and target positioning data is output. This eliminates the impact of network latency on positioning and ensures accurate location reference for hazard warning control, such as a position error of <1m for the 50m pre-activation strategy at the tunnel exit. Specifically, the vehicle positioning module combines the fused GNSS observations with the differential correction information and uses RTK (Real-Time Kinematics) technology for differential calculation to eliminate common errors and improve positioning accuracy to the centimeter level. For sections without GNSS signals, such as tunnels, continuous positioning is provided by visual SLAM and IMU, with errors typically controlled within ±2m.

[0104] In some cases, the receiving frequency of differential correction information is configured to ensure the real-time performance of dynamic positioning. If V2X communication is interrupted, the system degrades to multi-source fusion positioning, but it can still meet the needs of most scenarios. Positioning accuracy can also be evaluated after positioning. The accuracy evaluation results are fed back to the data fusion and positioning error detection module to optimize the fusion algorithm weights, adjust the error detection threshold, and update sensor calibration parameters, forming a closed-loop iterative optimization. Actual measurement or comparative testing methods can also be used to evaluate the accuracy of the final positioning result.

[0105] The system pre-configures specific geographic locations that need to trigger hazard warnings and their trigger distance thresholds in the memory. The edge computing unit acquires target location data in real time and calculates the shortest distance between the vehicle's current location and the boundary of the preset specific area. If this distance is less than or equal to the preset threshold, it is determined that the geographic location threshold is met. When the geographic location threshold condition is met, the system considers that the geographic location-related hazard warning light activation condition has been triggered. At this time, the edge computing unit outputs a high-level control signal to the hazard warning light driver circuit through the GPIO interface. The driver circuit provides a large instantaneous current to the hazard warning light, causing the hazard warning light to illuminate. It should be noted that the activation condition in this implementation may also include other environmental thresholds. The example only refers to the geographic location threshold; the activation conditions for other driving scenarios may also include other thresholds.

[0106] Simultaneously with illuminating the hazard warning lights, the edge computing unit sends a notification to the in-vehicle human-machine interface (HUD), such as "Approaching tunnel exit" or "Hazard warning activated," informing the driver that the hazard warning lights have been activated by the system. The HUD can be, but is not limited to, the instrument panel and a head-up display (HUD).

[0107] To resolve human-computer interaction conflicts, step 103 further includes generating a control command to activate the hazard warning light and disabling the manual shutdown command when the risk level parameter is at a first preset level. And / or, when the risk level parameter is at a second preset level, generating a control command to activate the hazard warning light and outputting a human-computer interaction prompt that allows manual shutdown; acquiring driver status monitoring parameters; and after the control command is output, if the driver status monitoring parameters are detected to be below a preset threshold, forcibly activating the hazard warning light and disabling the manual shutdown command.

[0108] Reference Figure 8 , Figure 8 This is a flowchart illustrating the hierarchical human-machine decision-making logic. Control authority is dynamically allocated based on risk level, and the interaction logic is optimized by incorporating driver status monitoring.

[0109] Before or simultaneously with the generation of the hazard warning light control command, the system obtains the risk level parameters (first preset level or second preset level) of the current driving scenario from the scene recognition process, and obtains driver state monitoring parameters from the driver monitoring system (DMS). These driver state monitoring parameters include: steering wheel grip force (unit: N), gaze deviation time (unit: s), and eye-closing frequency. Preset thresholds include: steering wheel grip force < 5N is considered distraction; gaze deviation from the road surface > 2s is considered fatigue.

[0110] If the risk level is the first preset level, the system directly generates a control command to activate the hazard warning lights. This control command drives the hazard warning lights to illuminate via a high-level GPIO output, while simultaneously setting the control flag to a locked state, blocking any manual shutdown commands from the hazard warning lights. The driver cannot turn off the hazard warning lights via physical buttons to avoid accidental interruption of the warning system until the risk is eliminated, such as when deceleration returns to normal and the system determines it is safe.

[0111] If the risk level is the second preset level, the system generates a control command to activate the hazard warning lights. This command also illuminates the hazard warning lights, but initially, the driver is allowed to manually turn them off. At this time, the human-machine interface displays messages such as "The system has activated the hazard warning lights; they can be manually turned off" and "The driver has turned off the hazard warning lights." This ensures information transparency and enhances the safety of human-machine collaboration.

[0112] Simultaneously, the system starts a monitoring timer to continuously read driver status monitoring parameters and record operation logs, including timestamps, hazard levels, and driver actions, which can be used for accident tracing. If the driver status monitoring parameters are detected to be below a preset threshold, such as a gaze deviation > 2 seconds, the system automatically upgrades the current execution strategy. Upgrade operations include, but are not limited to: switching the control flag to a locked state, such as upgrading from "can be manually turned off" to "cannot be manually turned off," and outputting a warning "driver status abnormal, hazard warning locked" through the human-machine interface. After this, manual shutdown commands are blocked, and the hazard warning lights remain illuminated until the system determines that the risk has been eliminated. For example, when the system determines that the risk level of the current driving scenario has decreased, the forced activation state is deactivated, allowing manual shutdown or automatic shutdown of the hazard warning lights, such as when the vehicle has exited a tunnel, deceleration has returned to normal, or the driver's focus has returned.

[0113] This embodiment employs a dual-dimensional decision-making mechanism based on hazard level and driver status to ensure the safety and rationality of control allocation.

[0114] To ensure a fast response (≤5ms) for the hazard warning lights, a MOSFET driver circuit is used, refer to... Figure 9 , Figure 9 This is a circuit diagram for driving a hazard warning light.

[0115] Among them, the control signal is the PWM signal output by the MCU (duty cycle 100% → always on); the drive stage is the high-speed optocoupler (6N137) that isolates the MCU (3.3V) from the drive circuit (12V); the power stage is the N-channel MOSFET (IRF540, on-resistance 28mΩ) that directly drives the hazard warning light; the protection circuit is the freewheeling diode (1N5819) that absorbs the back electromotive force of the inductor to prevent the MOSFET from breaking down.

[0116] The hazard warning light driver circuit diagram in the example above supports 12V / 5A output, which meets the requirements of a 35W hazard warning light.

[0117] This concludes the description of the method embodiment. The modules described above, through low-latency hardware architecture, multimodal perception fusion, dynamic scene modeling, high-precision positioning, and hierarchical human-machine decision-making, systematically solve the problems of response delay, unreliable perception, poor adaptability, positioning deviation, and human-machine conflict in hazard warning control under complex weather and special scenarios, providing a verifiable and implementable technical solution for vehicle active safety.

[0118] To make the above embodiments easier to understand, a specific embodiment is given below, taking an emergency braking scenario as an example. (Refer to...) Figure 10 , Figure 10 The timing diagram of the entire link from emergency braking to hazard warning light activation verifies the core indicator of the present invention: response time ≤200ms.

[0119] Reference Figure 10 The time delay is accumulated as Δt1+Δt2+Δt3+Δt5+Δt6+Δt7≤200ms (Note: Δt4 is usually not included in the response time because it represents the manifestation of the braking effect, not the system response). According to actual tests, the total response time from emergency braking trigger (T0) to hazard warning light activation (T0+Δt7) is ≤200ms.

[0120] This application provides a method, device, and storage medium for controlling vehicle hazard warning lights, which has the following beneficial effects: By acquiring vehicle perception data of the surrounding environment and identifying the current driving scenario, the system can distinguish different driving environments and then match the corresponding hazard warning light activation conditions according to the scenario type. This avoids the false triggering or delayed response of traditional fixed threshold triggering mechanisms in complex scenarios. Subsequently, when the vehicle perception data meets the dynamic activation conditions, a control command is generated to achieve adaptive and precise activation of the hazard warning lights in complex driving environments, reducing the risk of secondary accidents.

[0121] Figure 11 An example is a schematic diagram of the physical structure of a vehicle hazard warning light control device, such as... Figure 11 As shown, the vehicle hazard warning light control device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840. The processor 810, communication interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logic instructions stored in the memory 830 to execute the vehicle hazard warning light control method.

[0122] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the vehicle hazard warning light control method provided by the above methods.

[0124] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the vehicle hazard warning light control methods provided by the above methods.

[0125] It should be noted that the technical solutions or features described in the above embodiments can be combined or supplemented with each other without conflict. The scope of protection of this application is not limited to the precise structures described in the above embodiments and shown in the accompanying drawings; all modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for controlling vehicle hazard warning lights, characterized in that, The method includes: Acquire vehicle perception data, including at least the vehicle's surrounding environment, and identify the current driving scenario based on the vehicle perception data; Determine the hazard warning light activation conditions corresponding to the current driving scenario, wherein different driving scenarios correspond to different hazard warning light activation conditions; When the vehicle perception data meets the hazard warning light activation conditions, a control command for the hazard warning light is generated.

2. The vehicle hazard warning light control method as described in claim 1, characterized in that, The determination of the hazard warning light activation conditions corresponding to the current driving scenario includes: Determine the risk level parameters for the current driving scenario; When the risk level parameter is the first preset level, the activation threshold corresponding to the current driving scenario is read from the preset scenario mapping table as the activation condition of the hazard warning light. The scenario mapping table contains preset driving scenarios with mapping relationships and corresponding preset activation thresholds.

3. The vehicle hazard warning light control method as described in claim 2, characterized in that, After obtaining the hazard level of the current driving scenario, the method further includes: When the risk level parameter is the second preset level, the activation threshold is calculated in real time based on the three-dimensional dynamic scene model to generate the activation conditions for the hazard warning light. The three-dimensional dynamic scene model is a parameterized model of online reinforcement learning, which includes at least road feature dimension, meteorological condition dimension and vehicle state dimension, and is used to output the corresponding hazard warning light activation threshold based on the input vehicle perception data.

4. The vehicle hazard warning light control method as described in claim 3, characterized in that, The control command for generating the hazard warning light includes: When the risk level parameter is at the first preset level, a control command to activate the hazard warning light is generated, and the manual shutdown command is disabled; and / or When the risk level parameter is the second preset level, a control command to activate the hazard warning light is generated, and a human-machine interaction prompt that allows manual shutdown is output. If the driver status monitoring parameters are detected to be lower than a preset threshold after the control command is output, the hazard warning light is forcibly activated and the manual turn-off operation command is blocked.

5. The vehicle hazard warning light control method as described in claim 1, characterized in that, When the vehicle perception data meets the hazard warning light activation condition, a control command for the hazard warning light is generated, including: The vehicle positioning data is obtained from the vehicle perception data, which is obtained through multi-source fusion positioning. Obtain differential correction information broadcast in real time from the roadside unit, correct the vehicle positioning data according to the differential correction information, and output the target positioning data; Determine whether the target location data meets the geographical location threshold for triggering a hazard warning; If the conditions are met, the activation conditions for the hazard warning light are satisfied, and a control command for the hazard warning light is generated.

6. The vehicle hazard warning light control method as described in claim 5, characterized in that, The multi-source fusion positioning includes: When satellite signals for the vehicle are available, satellite positioning data and differential correction information are fused to obtain the vehicle positioning data; When satellite signals for the vehicle are unavailable, visual positioning data and inertial navigation positioning data are fused to obtain the vehicle positioning data.

7. The vehicle hazard warning light control method as described in claim 1, characterized in that, The step of identifying the current driving scenario based on the vehicle perception data includes: The vehicle perception data is fused to obtain fused perception data; The fused perception data is input into a preset three-dimensional dynamic scene model, and the current driving scene is output.

8. The vehicle hazard warning light control method as described in claim 7, characterized in that, The vehicle perception data is fused to obtain fused perception data, including: Feature extraction is performed on at least one of the vehicle perception data to obtain the scene features of the current driving scene; The weights of the vehicle perception data in different modalities are dynamically adjusted based on the scene characteristics. The vehicle perception data is weighted and fused with the corresponding adjusted weights to obtain the fused perception data.

9. The vehicle hazard warning light control method as described in claim 8, characterized in that, The method further includes: A time-series model is used to detect conflicts between vehicle perception data of different modalities. When a data conflict is detected, a Kalman filter is activated for correction. Feature extraction is performed on at least one corrected vehicle perception data to obtain the scene features of the current driving scenario.

10. The vehicle hazard warning light control method as described in claim 8, characterized in that, The in-vehicle terminal is equipped with a lightweight edge computing unit, which includes an FPGA. Before extracting features from at least one of the vehicle perception data to obtain the scene features of the current driving scene, the method further includes: At least one of the vehicle perception data is preprocessed using hardware acceleration via FPGA. The preprocessed vehicle perception data is then used for feature extraction to obtain the scene features of the current driving scenario.

11. An electronic device, characterized in that, The system includes a memory, a processor, and a vehicle hazard warning light control program stored in the memory and executable on the processor. When the processor executes the vehicle hazard warning light control program, it implements the vehicle hazard warning light control method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a vehicle hazard warning light control program, which, when executed, implements the vehicle hazard warning light control method as described in any one of claims 1 to 10.

Images