A special vehicle task state recognition method, a traffic signal control method, a system and a medium

Abstract

The application provides a special vehicle task state recognition method, a traffic signal control method, a system and a medium. The method comprises the following steps: acquiring road video data to detect special vehicles, setting a track identification number for the special vehicles and continuously tracking the special vehicles to generate a detection result; for each track identification number, corresponding warning light images are extracted frame by frame in the detection result and color detection is performed to obtain the on-off state of the warning light to form a flickering history sequence; for each flickering history sequence, autocorrelation analysis is performed to obtain a corresponding peak amplitude and frequency; for each track identification number, if the peak amplitude reaches a preset peak amplitude threshold and the frequency is between 1HZ and 4HZ, the corresponding special vehicle is identified as being in a task state. In the application, through visual detection and cross-frame tracking of the special vehicle, local area extraction and frame-by-frame color detection of the warning light, and multi-frame time sequence autocorrelation analysis, the reliability and efficient identification of the task state judgment are realized.

Description

Technical Field

[0001] This application relates to the field of image processing, and in particular to a method for recognizing the mission status of special vehicles, a traffic signal control method, a system, and a medium. Background Technology

[0002] In current road traffic control, priority passage is sometimes required for special vehicles on duty. Existing technologies for prioritizing special vehicles mainly include: 1) V2X on-board unit communication: Special vehicles are equipped with dedicated on-board units (OBUs) that send priority requests to roadside equipment via V2X communication. However, this solution requires all special vehicles to be equipped, resulting in low coverage, and the equipment requires continuous maintenance and updates; 2) Acoustic detection (siren recognition): Detecting siren sounds through a microphone array. The disadvantages of this solution are significant background noise interference in urban areas (construction, horns, music, etc.), high false alarm rates, and inability to determine whether a vehicle is actually performing a task; 3) Appearance-based image recognition: Identifying special vehicle types through vehicle exterior paint (color, markings). The disadvantage is that it can only identify "what kind of vehicle," not "whether it is performing a task"; 4) Manual triggering: Drivers manually switch signals by notifying the traffic management center via a dedicated button or telephone. The disadvantages are large response delays, complex operation, and unsuitability for emergency scenarios.

[0003] It should be noted that the above introduction to the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background section of this application. Summary of the Invention

[0004] The purpose of this invention is to provide an image processing method to achieve task status recognition of mission vehicles through visual analysis.

[0005] To address the aforementioned problems, firstly, a method for identifying the mission status of special vehicles is provided, comprising the following steps: S1. Acquire road video data for special vehicle detection, assign a unique trajectory identifier to each special vehicle and continuously track it to generate special vehicle detection results; S2. For each of the trajectory identifiers, extract the corresponding warning light image of the special vehicle frame by frame from the special vehicle detection result and perform color detection to obtain the on / off state of each frame of the warning light image to form a flashing history sequence. S3. Perform autocorrelation analysis on the flickering history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency; S4. For each trajectory identifier, if the peak amplitude reaches a preset peak amplitude threshold and the frequency is between 1Hz and 4Hz, the corresponding special vehicle is identified as being in a mission state.

[0006] In this application, by performing visual inspection and cross-frame tracking of special vehicles, extracting local areas of warning lights and performing frame-by-frame color detection, and conducting multi-frame temporal autocorrelation analysis, the reliability and efficiency of task status judgment are achieved.

[0007] In step S1, special vehicles are detected in the road video data based on the YOLO convolutional neural network; and multi-target continuous tracking is performed on each detected special vehicle based on the IoU matching algorithm.

[0008] In step S2, the process of extracting the warning light image of the corresponding special vehicle includes: based on the detection result of the special vehicle, obtaining the current frame image containing the special vehicle and the detection box coordinates; in the current frame image, cropping a preset area corresponding to the detection box coordinates as the warning light image, wherein the preset area is the top preset ratio area in the detection box coordinates.

[0009] In step S2, the process of color detection of the warning light image includes: converting the warning light image into a to-be-processed image that includes at least chroma information and saturation information, wherein the chroma information includes red and blue; setting a red threshold range, a blue threshold range, and a saturation threshold; selecting the pixels in the to-be-processed image that satisfy at least one of the red threshold range or the blue threshold range and simultaneously satisfy the corresponding saturation threshold as target pixels; calculating the proportion of the target pixels in the to-be-processed image; outputting a true value when the proportion reaches a preset lighting threshold and an false value when the proportion does not reach the preset lighting threshold, thereby obtaining the on / off state of the warning light image.

[0010] In step S3, the process of performing autocorrelation analysis on the flickering history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency includes: mapping each flickering history sequence to a first numerical sequence by mapping the true value to +1 and the false value to -1; subtracting the mean of the first numerical sequence from all numbers in the first numerical sequence to obtain a second numerical sequence; calculating the autocorrelation function on the second numerical sequence and performing peak search within the search interval to obtain the corresponding peak amplitude and frequency; the search interval is [min_lag, max_lag], where min_lag=max(1, int(fps / 8)), max_lag=min(N-1, int(2fps)), int is the floor function, fps is the sampling rate of the road video data, and N is the number of sequences in the flickering history sequence.

[0011] Step S4 further includes: when the peak amplitude is less than 0.3, identifying the corresponding special vehicle as not in a mission state; when the peak amplitude is not less than 0.3, calculating the frequency of the second numerical sequence; when the peak amplitude reaches 0.75 and the frequency is between 1 Hz and 4 Hz, identifying the corresponding special vehicle as in a mission state.

[0012] The process of performing multi-target continuous tracking of each detected special vehicle based on the IoU matching algorithm includes: constructing a current trajectory tracking pool: constructing a set of currently active trajectories in the tracking pool, each trajectory including the trajectory identifier, detection box coordinates, consecutive lost frames, and the flashing history sequence corresponding to the trajectory identifier; performing detection confidence differentiation: determining the detection confidence of the special vehicle detection result in the current frame, recording the special vehicle detection results with a detection confidence of not less than 0.5 as high-confidence detection results, and recording those with a confidence of less than 0.5 as low-confidence detection results; performing high-confidence matching: matching the high-confidence detection results with the high-confidence detection results. The detection results are compared with the trajectories in the tracking pool using IoU matching. If a match is successful, the corresponding flicker history sequence is updated. Low-confidence matching is performed: the low-confidence detection results are compared with the trajectories that did not match in the high-confidence matching. If a match is successful, the corresponding flicker history sequence is updated. New trajectory creation and invalid trajectory cleanup are performed: new trajectories are created for the high-confidence detection results that still do not match after the high-confidence matching is completed. The number of consecutive lost frames of the trajectories that still do not match after the low-confidence matching in the tracking pool is incremented by 1. When the number of consecutive lost frames exceeds a preset limit, the corresponding trajectory is removed.

[0013] Secondly, this application also provides a special vehicle mission status recognition system, including: The camera module is used to acquire road video data; An edge computing module is used to execute a special vehicle mission status recognition method as described in any one of the first aspects.

[0014] Thirdly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a special vehicle mission status identification method according to any one of the first aspects.

[0015] Fourthly, this application also provides a traffic signal control method for special vehicles, which first executes the special vehicle task status identification method described in any one of the first aspects; When a special vehicle is on a mission and the light for the direction of origin of the special vehicle is green, the current green light time shall be maintained or extended to allow the special vehicle to pass. When a special vehicle is on duty and the light for its direction of origin is not green, a safety clearance should be performed first. Then, the light for the direction the special vehicle is originating should be set to green, and the light for the other directions should be set to red to allow the special vehicle to pass. Compared with existing technologies, the beneficial effects of this invention mainly include the following: Compared with V2X active request schemes, siren acoustic schemes, and simple appearance recognition schemes, the core advantage of this invention lies in separating and then fusing "identity recognition" and "task status recognition," and using two quantitative indicators, frequency and confidence level, to constrain the final triggering logic. The accuracy of traditional V2X schemes is highly dependent on the installation rate of on-board equipment and the active request link, while appearance recognition schemes can only answer "is this a special vehicle?" but cannot answer "does it currently have priority passage?" This invention, through the physical behavior characteristic of the periodic flashing of warning lights, directly incorporates the latter question into the calculation object. Acoustic detection is easily affected by urban noise, reflection, and obstruction, while this invention uses autocorrelation to perform time-domain analysis on the on / off sequence. Only when the flashing frequency falls within the effective range of 1 to 4 Hz and the confidence level exceeds the threshold is it determined to be a task execution, thus reducing false alarms caused by random noise from a mechanism perspective. In terms of timeliness, the present invention can complete the task determination in as little as 10 frames, and the priority triggering basis can be formed in about 0.4 seconds at 25fps; this time scale can meet the real-time requirements of intersection signal control for priority of special vehicles. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This invention provides a flowchart for special vehicle mission status recognition.

[0018] Figure 2 This invention provides a two-stage IoU matching and tracking flowchart.

[0019] Figure 3 This is a schematic diagram of the warning light image extraction provided by the present invention.

[0020] Figure 4 This is a schematic diagram of color detection in the HSV color space provided by the present invention.

[0021] Figure 5 This is a schematic diagram of the second numerical sequence provided by the present invention.

[0022] Figure 6 This is a schematic diagram of autocorrelation calculation and peak search provided by the present invention.

[0023] Figure 7 This invention provides an overall architecture diagram of a special vehicle mission status recognition system.

[0024] Figure 8 This invention provides a flowchart of a special vehicle task traffic signal control process. Detailed Implementation

[0025] The foregoing and other technical contents, features, and effects of the present invention will be clearly presented in the following detailed description of a preferred embodiment with reference to the accompanying drawings. The directional terms mentioned in the following embodiments, such as up, down, left, right, front, or back, are merely for reference to the accompanying drawings. Therefore, the directional terms used are for illustrative purposes and not for limiting the present invention.

[0026] The embodiments of this application will now be described in detail with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the embodiments of this application to facilitate a better understanding of the application. However, the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0027] Example 1 This invention provides a method for identifying the mission status of special vehicles. Please refer to the following references. Figures 1 to 6 As shown. First Figure 1 A flowchart for special vehicle mission status identification is shown. (Reference) Figure 1This invention provides a method for identifying the mission status of special vehicles, comprising the following steps: acquiring road video data for special vehicle detection; assigning a unique trajectory identifier to each special vehicle and continuously tracking it to generate a special vehicle detection result; for each trajectory identifier, extracting the corresponding warning light image of the special vehicle frame by frame from the special vehicle detection result and performing color detection to obtain the on / off state of each frame of the warning light image to form a flashing history sequence; performing autocorrelation analysis on the flashing history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency; for each trajectory identifier, if the peak amplitude reaches a preset peak amplitude threshold and the frequency is between 1Hz and 4Hz, identifying the corresponding special vehicle as being in a mission status. Specifically: Step 1: Acquire road video data and perform special vehicle detection and tracking; In this embodiment, video data is processed using a YOLO convolutional neural network to identify special vehicles within the video data. It should be noted that the special vehicle target detection method based on convolutional neural networks such as YOLO (e.g., YOLOv5 / YOLOv8 target detection models) used in this application is a well-established and publicly available technology in the field. This invention does not improve the network structure or algorithm of the detection model itself, but merely uses it as a source of pre-processing data input. Therefore, the identification process of special vehicles will not be described in detail here. In existing YOLO convolutional neural networks, class-id==3 corresponds to the detection of special vehicles.

[0028] The YOLO convolutional neural network can automatically detect special vehicles in input road video data and extract information about them in each frame, labeling them with bounding boxes. YOLO detection typically represents detected special vehicles as bounding boxes, with the box coordinates corresponding to the pixel area occupied by the detected special vehicle in that frame of video.

[0029] It should be understood that multiple special vehicles may exist simultaneously in the road video data at each intersection. Therefore, it is necessary to ensure the correspondence of data for each vehicle to prevent data from different vehicles from being mixed up and affecting the subsequent analysis and identification process. That is, it is necessary to establish a correspondence between the detection results of each special vehicle to achieve cross-frame identification of the same vehicle. To this end, after the presence of a special vehicle is detected, a unique track identifier (track_id) is created for each special vehicle, and the location information of the special vehicle (i.e., the detection box coordinates) is mapped to its track identifier for subsequent analysis and processing.

[0030] It is understandable that the correct execution of the task status recognition process for special vehicles fundamentally depends on the premise that "the same special vehicle is correctly associated with the same flashing history sequence in several consecutive frames." Since special vehicles are dynamic targets moving over time, their pixel coordinates, detection box size, and aspect ratio in the video frame sequence change frame by frame. Furthermore, multiple vehicles (including multiple special vehicles, multiple civilian vehicles, and various traffic participants) may exist simultaneously in the same intersection scene. Without a stable cross-frame target association mechanism, it cannot be guaranteed that the on / off states observed in frame t, frame t+1, ..., frame t+N-1 all originate from the same special vehicle, and it is impossible to accumulate statistically significant continuous flashing sequences for autocorrelation analysis. Therefore, this embodiment also provides a multi-target tracking mechanism, which can serve as a front-end support and data association layer for the main task status recognition link, directly providing the core input of "flashing sequences grouped by vehicle identity" for the autocorrelation calculation of the aforementioned multi-frame temporal images corresponding to the flashing history sequences.

[0031] In this embodiment, multi-target continuous tracking is performed on each detected special vehicle based on the IoU matching algorithm. This multi-target tracking mechanism employs a "high- and low-confidence hierarchical two-stage IoU matching" strategy to perform cross-frame identity association for special vehicles, minimizing trajectory interruptions caused by short-term occlusion, motion blur, or detector errors, and their subsequent impact on the integrity of the flash sequence. Its basic working process can be further detailed as follows: First, the current trajectory tracking pool is constructed: the tracker internally maintains a set of currently active tracks. Each track includes a track identifier, detection box coordinates, consecutive lost frames (lost_count), and a flash history sequence (flash_history) corresponding to the track identifier. The flash history sequence is a Boolean sequence of on / off states appended frame by frame, which is the direct input for subsequent autocorrelation analysis. In this embodiment, its storage limit is set to approximately the number of frames corresponding to two seconds (e.g., 50 frames at 25fps), meaning only the data from the most recent few frames is retained and updated using a sliding window method. In other embodiments, the storage limit of the flash history sequence can be set to other values; this is not strictly limited.

[0032] Then, the system classifies the results based on the detection confidence level. All target detection results in the current frame are categorized according to the detection confidence level: those with a confidence level ≥ 0.5 are considered "high-confidence detection results," while those below 0.5 are recorded as "low-confidence detection results." In this embodiment, the threshold for high and low confidence is set to 0.5. In other embodiments, it can be set to other values, such as 0.6 or 0.7.

[0033] Next, the matching process begins, starting with high-confidence matching (Stage A). These high-confidence detection results are correlated with all active trajectories in the tracking pool (i.e., trajectories that have not yet been lost or terminated). The correlation is based on the IoU (Intersection over Union) between the detection bounding box and the trajectory prediction bounding box. In this embodiment, the matching threshold is set to 0.3 (i.e., an IoU exceeding 0.3 is considered a possible match); in other embodiments, the matching threshold can be changed according to the actual situation. If a high-confidence detection result successfully matches an existing trajectory, it is appended to the corresponding track_id's flashing history sequence and its lost_count is reset (set to 0); unsuccessfully matched "high-confidence detection results" are considered potential new vehicles and enter the subsequent new trajectory creation process.

[0034] Next, low-confidence matching (Stage B) is performed. For the remaining active trajectories that failed to match the high-confidence detection results in Stage A, a second IoU match is further attempted with the "low-confidence detection results" with a confidence level below 0.5 in the current frame. This stage is specifically designed to handle situations where the confidence level of YOLO-type detectors decreases due to short-term occlusion, sudden changes in lighting, or motion blur. By allowing these low-confidence detections to temporarily "claim" existing trajectories, the accumulation of the flickering history sequence is prevented from being mistakenly identified as lost targets due to confidence fluctuations in one or two frames.

[0035] Finally, new tracks are created and invalid tracks are cleaned up. High-confidence detection results that have not matched after Stage A are treated as newly appearing vehicles and assigned a brand new track_id, while an empty flashing history sequence is created. For active tracks that have not matched after Stage B, their lost_count is incremented by 1. When the number of consecutive lost frames exceeds a preset limit (e.g., 30 frames, approximately 1.2 seconds at 25fps), the track is officially removed from the tracking pool, and its corresponding flashing history sequence is cleaned up simultaneously to prevent invalid data from interfering with the task status recognition of other vehicles.

[0036] After the aforementioned two-stage IoU matching mechanism with high and low confidence levels, the flashing history sequence corresponding to each trajectory identifier can stably accumulate only the on / off state samples of the "same physical vehicle," providing high-quality input data for subsequent autocorrelation analysis. Correspondingly, since the task status determination of the same vehicle always revolves around a fixed trajectory identifier, the subsequent priority passage control triggering results can also be strictly correlated with the vehicle's identity and the lifecycle of its current trajectory (e.g., "the same vehicle only triggers priority mode once," "the priority flag is automatically cleared after the vehicle leaves the field of view," etc.), further improving the interpretability and controllability of task recognition and signal control linkage. The corresponding pseudocode implementation flow is given below to more clearly illustrate the above two-stage IoU matching process: Stage A: High-confidence detection (confidence ≥ 0.5) and matching with existing tracking. Greedy matching using IoU (Intersection over Union) with a threshold ≥ 0.3 Stage B: Low-confidence detection (confidence < 0.5) is used for secondary matching with unmatched traces from Stage A. → Reduce tracking loss due to occlusion / blurring Unmatched high-confidence detection → Create new trace Tracking that results in a continuous loss of more than 30 frames → Remove (and simultaneously clear the corresponding flicker history). Step 2: Based on the trajectory identifier, extract the warning light area of ​​each special vehicle frame by frame and perform color detection to form a flashing history sequence; In step 1, the detection of special vehicles and the generation of trajectory identifiers have been carried out; then for each trajectory identifier, the video frame corresponding to the special vehicle and the coordinates of the detection box in the video frame can be obtained.

[0037] It is understandable that the warning lights of special vehicles are located above the vehicles. To reduce computational resources and eliminate interference from vehicle color (such as a red fire truck) on subsequent detection, video frames can be cropped so that only the area containing the warning lights is analyzed later. Specifically, the process of extracting the corresponding warning light image of a special vehicle includes: based on the special vehicle detection results, obtaining the current frame image containing the special vehicle and the coordinates of the detection box; in the current frame image, cropping a preset area from the corresponding detection box coordinates as the warning light image, the preset area being the top preset proportion area in the detection box coordinates.

[0038] Specifically, for the same trajectory identifier, using the special vehicle detection box coordinates (x1, y1, x2, y2) and the current video frame as input, the height of the warning light candidate region, light_h, is first calculated by multiplying the detection box height h by a preset cropping ratio (preferably 0.25, i.e., one-quarter of the detection box height) and ensuring it is at least 1 pixel to prevent degradation. Then, using the upper left corner of the detection box as a reference, light_h rows of pixels are extended downwards and cropped at the boundary to obtain the effective sub-region coordinates (light_x1, light_y1, light_x2, light_y2) within the image frame. Finally, this sub-region is cropped from the current video frame as the warning light region image light_region. If the cropping result is empty, an empty value is returned directly to skip subsequent processing. The corresponding pseudocode implementation flow is given below: Input: Detection box bbox = (x1, y1, x2, y2), video frame. Step 1: Calculate region height h = y2 - y1 light_h = int(h × LIGHT_REGION_RATIO) # LIGHT_REGION_RATIO = 0.25 light_h = max(light_h, 1) # At least 1 pixel. Step 2: Boundary check light_y1 = max(0, y1) light_y2 = min(frame_height, y1 + light_h) light_x1 = max(0, x1) light_x2 = min(frame_width, x2) Step 3: Extract sub-image light_region = frame[light_y1 : light_y2, light_x1 : light_x2] If light_region area is 0 → Return None refer to Figure 3 As shown, in this embodiment, the preset area is the preset proportion area at the top of the detection box coordinates, specifically the top 25% proportion area; in other embodiments, other cropping proportions may also be used, such as 15%, 20%, 25%, 30%, etc.

[0039] After acquiring the warning light image, color detection needs to be performed on the warning light image to generate the on / off state of the warning light area of ​​the same vehicle frame by frame, and a Boolean-type flashing history sequence is output.

[0040] In this embodiment, the on / off state of the warning light in the current frame is determined by performing color detection frame by frame on the cropped warning light area image. The color detection process includes: filtering target pixels belonging to the on state of the warning light based on the rule that the chromaticity component is located in the red / blue threshold range and the luminance and / or saturation components meet the lower limit of the threshold; determining the on / off state based on whether the proportion of the target pixel in the warning light area image reaches a preset lighting threshold, with those exceeding the threshold indicating the light is on and those below the threshold indicating the light is off.

[0041] Specifically, in this embodiment, the HSV color space is used as an example to illustrate the specific implementation process: 1) Define the color threshold, referring to... Figure 4 As shown: In the HSV color space, the detection ranges for red and blue are defined as follows: Red range 1 (warm red): H∈[0,10], S∈[100,255], V∈[100,255] Red range 2 (cold red): H∈[160,180], S∈[100,255], V∈[100,255] Blue range: H∈[100,130], S∈[100,255], V∈[100,255] The HSV color space separates hue (H), saturation (S), and value (V), making color detection more robust to changes in lighting (day / night / shadow). The dual constraints of high saturation (S>100) and high value (V>100) effectively filter out low-saturation environmental colors (such as sky and road reflections).

[0042] 2) Analyze the warning light area image frame by frame and calculate the proportion of target pixels; First, the input warning light region image (light_region) is converted from the BGR color space to the HSV color space. Then, binary masks are generated according to the red and blue intervals defined above (target pixels satisfying the above threshold definition are 1 after binarization, and 0 otherwise). The sum of the number of pixels with "1" in the three masks is then counted and divided by the total number of pixels in the warning light region image to obtain the target pixel ratio. Finally, this ratio is compared with the preset lighting threshold LIGHT_ON_RATIO (preferably 0.05 in this embodiment). If the threshold is reached or exceeded, it is determined as "light on", otherwise it is determined as "light off". Finally, the Boolean result (True or False) is output as the flashing state of this frame.

[0043] The corresponding pseudocode implementation process is given below: Input: Warning light region image (light_region) (BGR format) Step 1: Color Space Conversion hsv = cvtColor(light_region, BGR2HSV) total_pixels = hsv.height × hsv.width Step 2: Color Mask Calculation mask_red1 = inRange(hsv, RED_LOWER_1, RED_UPPER_1) mask_red2 = inRange(hsv, RED_LOWER_2, RED_UPPER_2) mask_blue = inRange(hsv, BLUE_LOWER, BLUE_UPPER) Step 3: Proportion Calculation colored_pixels = count(mask_red1) + count(mask_red2) + count(mask_blue) ratio = colored_pixels / total_pixels Step 4: Judgment flash_state = (ratio ≥ LIGHT_ON_RATIO) # LIGHT_ON_RATIO = 0.05(5%) In this embodiment, the preferred illumination threshold is 5%, selected based on the following: when the warning light is illuminated, its pixel percentage in the vehicle roof area is typically between 8% and 30%; choosing 5% covers situations at long distances (where the light percentage decreases when the detection frame is small), while also eliminating occasional color interference (such as reflections when passing red buildings). It is understood that in other embodiments, the illumination threshold can be adaptively adjusted based on differences in the acquired road video data, different cropping ratios when acquiring the warning light image, etc., and this is not limited.

[0044] It should be noted that this invention does not limit the color space used for determining the on / off state of the warning light frame by frame to HSV. HSV color space is merely a preferred embodiment of this invention. Those skilled in the art should understand that any color space capable of separating chromaticity (hue) information from luminance information can be used for frame-by-frame determination of the proportion of high-saturation pixels in red and blue warning lights, such as YUV, YCbCr, YIQ, Lab (CIE L*a*b*), HSL, HSI, etc. In the aforementioned color spaces, this invention can also filter out target pixels belonging to the warning light's on state by setting red / blue threshold ranges for the chromaticity components and lower limits for the luminance and / or saturation components. When using these alternative color spaces, the technical solution and effects of this invention can all be achieved, and the corresponding target pixel determination threshold can be simply calculated based on the color space used. Specifically, for other formats, the warning light image can first be converted into an image to be processed that includes at least chroma information and saturation information, with the chroma information including red and blue; then, a red threshold range, a blue threshold range, and a saturation threshold are set, and the pixels in the image to be processed that satisfy at least one of the red threshold range or the blue threshold range and satisfy the saturation threshold are taken as target pixels; the proportion of the target pixels in the image to be processed is calculated, and when the proportion reaches the preset lighting threshold, a true value is output, and when the proportion does not reach the preset lighting threshold, a false value is output, so as to obtain the on / off state of the warning light image and form a Boolean flashing history sequence output.

[0045] Step 3: Perform autocorrelation analysis on the flicker history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency; First, for each trajectory identifier, obtain its blinking state in each frame in step 2, and accumulate them to form a corresponding blinking history sequence; the trajectory identifier and the corresponding blinking history sequence are uniquely matched.

[0046] In this embodiment, since the subsequent autocorrelation operation deals with continuous real-valued signals, preprocessing of the flash history sequence is required. The preprocessing includes: first, mapping the frame-by-frame Boolean flash history sequence `flash_history` to a first numerical sequence `signal` according to the rule "on → +1, off → -1"; then subtracting the mean of the first numerical sequence to eliminate DC bias (this step ensures that DC components such as all-on or all-off states do not produce spurious periodic peaks), resulting in a second numerical sequence, as referenced... Figure 5 As shown; finally, the standard deviation is used to determine whether the current signal is approximately constant (std is less than the preset minimum threshold, such as 0.1, which is considered constant). If so, (False, 0, 0) is returned directly to indicate no periodic flickering, thus skipping the subsequent autocorrelation calculation.

[0047] The pseudocode implementation flow of the preprocessing procedure is given below: Input: A sequence of flashing states from the most recent N frames: flash_history = [True, False, True, ...] Minimum frame rate requirement: N ≥ MIN_CONSECUTIVE_FRAMES (default 10 frames) Maximum number of frames retained: fps × 2 (i.e., the most recent 2 seconds) Step 1: Numericalization signal = [+1.0 if state else -1.0 for state in flash_history] Step 2: Remove the mean signal = signal - mean(signal) Step 3: Constant signal check If std(signal) < 0.1, return (False, 0, 0). (Full brightness or complete darkness does not constitute flickering) Next, the autocorrelation function is calculated for the preprocessed second numerical sequence that satisfies non-constancy. For example... Figure 6 As shown, the core of this step lies in peak extraction within the effective frequency band of the special vehicle warning light, which is 1Hz to 4Hz. Specifically, the `correlate` function is first used to calculate the complete autocorrelation sequence of the signal and itself, and the positive half (delay lag greater than or equal to 0) is truncated. Then, it is normalized by dividing by the value at zero delay (lag=0) so that the autocorrelation is 1 when lag=0. Subsequently, based on the preset flashing frequency range (1~4Hz) and video frame rate (fps), the minimum delay (min_lag) of the half-cycle and the maximum delay (max_lag) of the full cycle are calculated, thereby limiting a reasonable search interval [min_lag, max_lag] to avoid invalid searches or excessively high delays. Finally, the peak value of the autocorrelation coefficient is found within this search interval. The corresponding delay peak (peak_lag) represents the most important periodic interval in the signal, while the peak amplitude (peak_value) reflects the significance of the cycle and can be used to determine whether the target flashes at the expected frequency. The corresponding pseudocode implementation flow is given below: Step 4: Calculate the complete autocorrelation autocorr = correlate(signal, signal, mode='full') autocorr = autocorr[N-1:] # Take the positive half (lag ≥ 0) autocorr = autocorr / autocorr[0] # Normalization (lag=0 is 1.0) Step 5: Valid Search Range The corresponding flashing frequencies are [FLASH_FREQ_MIN, FLASH_FREQ_MAX] = [1Hz, 4Hz]: min_lag = max(1, int(fps / FLASH_FREQ_MAX / 2)) # Minimum half-cycle latency max_lag = min(N-1, int(fps / FLASH_FREQ_MIN × 2)) # Maximum latency over the entire cycle Step 6: Peak Search search_region = autocorr[min_lag : max_lag + 1] peak_offset = argmax(search_region) peak_lag = peak_offset + min_lag peak_value = autocorr[peak_lag] In this embodiment, the search interval is [min_lag, max_lag]. Since FLASH_FREQ_MAX is 4Hz and FLASH_FREQ_MIN is 1Hz, then min_lag = max(1, int(fps / 8)) and max_lag = min(N-1, int(2fps)), where int is the floor function, fps is the sampling rate of the road video data, and N is the number of sequences in the flash history sequence.

[0048] It should be noted that this invention does not require limiting the specific calculation implementation of the autocorrelation function to a single unified formula or a single operational function. The process described above, which involves "first directly calculating the complete autocorrelation, then taking the positive half for normalization, and then searching for the peak value within the search interval [min_lag, max_lag] determined by the sampling rate and the effective frequency band," is merely a preferred embodiment of this invention.

[0049] Those skilled in the art should understand that other mathematically equivalent or functionally equivalent autocorrelation implementations can be used as alternatives, such as: fast linear autocorrelation algorithms based on Fast Fourier Transform (FFT), autocorrelation estimates obtained by inverse power spectral density transformation based on Wiener-Khinchin theorem, biased / unbiased autocorrelation estimates, autocorrelation after windowing (such as Hanning or Hamming windows), piecewise averaged autocorrelation, bandwidth-normalized autocorrelation, and different implementations based on equivalent functions such as numpy.correlate or scipy.signal.correlate.

[0050] Furthermore, in different engineering environments, the above autocorrelation operation can be further adjusted and optimized according to computing power / latency requirements. For example, only calculating a few delay components located in the interval [min_lag, max_lag] can reduce the computational load, applying a sliding window smoothing to the autocorrelation value can improve the signal-to-noise ratio, or replacing the autocorrelation operation with an equivalent spectral peak extraction based on short-time Fourier transform can be used. Regardless of which implementation method is adopted, the core technical feature of this invention—"applying normalized autocorrelation operation to the flicker history column accumulated across frames of the same vehicle, performing peak extraction under the constraint of the effective frequency band of the special vehicle warning light from 1Hz to 4Hz, and then using the peak amplitude as a continuous confidence level for downstream task state recognition"—can all be achieved.

[0051] Step 4: For each trajectory identifier, if the peak amplitude reaches the preset peak amplitude threshold and the frequency is between 1Hz and 4Hz, the corresponding special vehicle is identified as being in mission status.

[0052] First, a significance check is performed on the peak amplitude (peak_value) obtained within the search interval [min_lag, max_lag]. If it is lower than the preset minimum confidence threshold (preferably 0.3 in this embodiment, but can be modified adaptively in other embodiments), it is directly determined to be non-periodic flickering, and the corresponding special vehicle can be identified as not in a task state. If it passes the significance check (peak amplitude is above 0.3), the flickering fundamental frequency (flickering fundamental frequency = sampling rate fps / peak delay peak_lag) is calculated, and this frequency is then checked again against the effective frequency band [1Hz, 4Hz] of the special vehicle warning light. The corresponding pseudocode implementation flow is given below: Step 7: Significance Check If peak_value < 0.3 → it is determined to be non-periodic flickering. Step 8: Frequency Calculation frequency = fps / peak_lag (Hz) Step 9: Frequency Range Verification is_valid = (FLASH_FREQ_MIN ≤ frequency ≤ FLASH_FREQ_MAX) That is: 1.0Hz ≤ frequency ≤ 4.0Hz For peak amplitude values ​​not less than 0.3, further assessment of the task status confidence is required. Specifically, the peak amplitude `peak_value` is used as the continuous confidence level (ranging from 0 to 1, corresponding to the strength of the flickering periodicity). Then, a logical AND operation is performed between the conditions "effective frequency via the flag `is_valid_frequency`" and "confidence reaching the preset peak amplitude threshold `EMERGENCY_CONFIDENCE_THRESHOLD` (in this embodiment, the preset peak amplitude threshold is preferably 0.75)". Only when both conditions are met is the special vehicle determined to be performing a task. The corresponding pseudocode implementation flow is given below: Input: peak_value (peak value of autocorrelation, 0.0-1.0) confidence = min(1.0, peak_value) Judgment conditions: is_on_duty = is_valid_frequency AND (confidence ≥ EMERGENCY_CONFIDENCE_THRESHOLD) Where EMERGENCY_CONFIDENCE_THRESHOLD = 0.75 The peak autocorrelation amplitude is a commonly used parameter reflecting the strength of the periodicity of a signal. The closer its value is to 1.0, the more regular the flickering, i.e., the stronger the periodicity. In this embodiment, when the peak amplitude is below 0.3, it can be directly determined as non-flickering without further judgment; the actual preset peak amplitude threshold is set to 0.75 to achieve a balance between reliability and sensitivity. In other embodiments, the preset peak amplitude threshold can be adaptively modified according to the actual application.

[0053] In this embodiment, autocorrelation analysis is used for flicker detection, which is inherently robust to the following interferences: 1) Random flicker (reflection, light and shadow changes): Its signal characteristics are non-periodic, and the autocorrelation response has no significant peak value, so it will not be misjudged; 2) Traffic light reflection: Its signal characteristics are periodic but the frequency is <1Hz, and the autocorrelation response has a peak value. When the frequency is outside the effective range, it will not be misjudged; 3) LED billboards: Its signal characteristics are high frequency >4Hz or constant brightness, and the autocorrelation response has a peak value but is outside the effective range or has no flicker, so it will not be misjudged; 4) Sun flicker (shading / exposure): Its signal characteristics are non-periodic, and the autocorrelation response has no significant peak value, so it will not be misjudged.

[0054] Example 2 This second embodiment provides a special vehicle mission status recognition system, including: a camera module for acquiring road video data; and an edge computing module for the special vehicle mission status recognition method described in the first embodiment.

[0055] For details, please refer to Figure 7 As shown, the camera module, i.e., the roadside camera, can capture road video data and input it to the edge computing module (i.e., the edge computing node) for processing. The edge computing module includes a visual detection unit for detecting special vehicles; a multi-target tracking unit for continuously tracking each special vehicle, with a tracking object pool set up to store the previous trajectory to achieve continuous tracking; a flicker analysis unit for forming a flicker history sequence and performing autocorrelation analysis; and a task determination unit that can determine the peak amplitude and frequency rules based on the results of the flicker analysis unit to identify whether the corresponding special vehicle is in a task state.

[0056] In addition, after identifying whether a special vehicle is on duty, the corresponding control command can be sent to the traffic signal controller through the signal control unit to adjust the traffic signal to ensure the priority passage of special vehicles.

[0057] The system's functionality was verified. The following functional characteristics were verified using automated test cases (all passed): 1. Task status trigger: The test scenario is task execution (on_duty=True, confidence=0.9), with the source direction not being the current green light; the verification result is successful generation of signal coverage instructions, and the target direction green light. 2. No handover required in the same direction: The test scenario is that the light in the source direction is already green; the verification result is None, and no handover is triggered. 3. Low-confidence rejection: The test scenario was on_duty=True, confidence=0.5 (below the 0.75 threshold); the verification result was rejection triggered. 4. Non-task rejection: The test scenario was on_duty=False, confidence=0.9; the verification result was rejection of triggering. 5. Vehicle Clearance: The test scenario involved clearing the record after a special vehicle passed by; the verification result showed no active special vehicles, and the system returned to normal mode. 6. Track ID Association: The test scenario involved slight positional shifts of the same target across consecutive frames (IoU > 0.3); the verification result showed that the target was correctly associated with the same track_id. 7. Two-stage matching: The test scenario is to detect and match existing tracking with low confidence (0.3); the verification result is that the tracking continues (frames +1). 8. Lost Tracking Cleanup: The test scenario was 6 consecutive frames with no matching detection (>max_lost=5); the verification result was that the tracking was removed. The system performance is as follows: 1. Complete control cycle delay: The measured value is P95 = 0.0061ms; the design target is ≤ 10ms. 2. Intersection controller initialization: Actual measured value is 0.20ms; design target is ≤ 1000ms 3. Maximum duration of priority for special vehicles: Actual measured value is 60s (configurable); Design target is 60s. 4. Tracker maximum loss tolerance: measured value is 30 frames (approximately 1.2s@25fps); design target is 30 frames. 5. Minimum frame rate for flicker analysis: Actual measured value is 10 frames (0.4s@25fps); Design target is 10 frames. 6. Maximum retention of flickering history: The measured value is 50 frames (2.0s@25fps); the design target is 50 frames. Example 3 This third embodiment provides a traffic signal control method for special vehicles, including: First, execute the special vehicle mission status recognition method described in Example 1; When a special vehicle is on a mission and the direction of origin of the special vehicle is green, maintain or extend the current green light time to allow the special vehicle to pass. When a special vehicle is on a mission and the light for the direction from which the special vehicle is coming is not green, the area should be cleared first, then the light for the direction from which the special vehicle is coming should be set to green, and the light for the other directions should be set to red, so that the special vehicle can pass.

[0058] Specifically, when a special vehicle is identified as being in a task state using a special vehicle task status recognition method, the system does not immediately trigger a priority switch. Instead, it first normalizes the source direction of the special vehicle (by removing modifiers such as "left turn" from the direction string) and compares it with the current green light direction set. If the direction in which the vehicle is located has already received a green light, it returns an empty value to avoid unnecessary mode switching (in this case, the current green light time can be directly extended to meet the priority passage requirement); if the two directions are inconsistent, the state machine generates a signal overriding instruction to set the direction in which the special vehicle is located. Set the light to green for all directions and red for the other directions, and set the maximum duration (preferably 60 seconds); before switching to the special vehicle priority mode, the state machine must first go through a 3-second yellow light and 3-second all-red light safety clearing process to ensure that vehicles that have entered the intersection can leave safely, and handle conflicts with other modes according to the priority order of "disaster evacuation (1) > special vehicle priority (2) > accident circuit breaker (3) > normal operation (4)"; finally, the priority mode is not abnormally locked by the dual mechanism of "automatic vehicle passage clearing" and "forced clearing after 60 seconds of timeout", and the normal operation mode is restored after clearing. The corresponding pseudocode implementation process is given below: Step 1: Direction Matching Check base_direction = vehicle_direction.replace("left", "") current_green_dirs = [d.replace("left","") for d in current_phase.directions] If base_direction ∈ current_green_dirs: → The source direction is already green, no need to switch (simply extend the current green light). → Return to None Step 2: Generate signal coverage instructions green_directions = [vehicle_direction] # Green light for special vehicle origin directions red_directions = [all other directions] # Red lights in other directions duration = EMERGENCY_VEHICLE_TIMEOUT (60s) # Maximum duration Step 3: State Machine Mode Switching Current Mode → Safe Clear (Yellow Light 3s → All Red 3s) → Special Vehicle Priority Mode Priority: Special vehicles first (2) > Accident circuit breaker (3) > Normal operation (4) Disaster evacuation mode only (1) can interrupt special vehicles priority Step 4: Timeout and Clearing - Automatic clearance after special vehicles pass through the intersection - If it fails to pass within 60 seconds, the timeout will be automatically cleared. - Restore normal operating mode after clearing The following section provides a comparative analysis of two scenarios: one involving performing a task and the other not. This analysis further explains the process by which the present invention identifies the task status of special vehicles and controls traffic signals. Through these two contrasting examples, the innovations of this invention compared to traditional visual recognition solutions can be more intuitively demonstrated.

[0059] Test Case 1: Automatic Recognition and Priority Triggering of Ambulances Approaching Intersections on Duty 1. The camera captured an ambulance entering the field of view on the east entrance road. The YOLO model identified it as a special vehicle and assigned a unique track_id by the tracker.

[0060] 2. The system extracts the warning light detection area from the top 25% of the vehicle detection frame and detects the periodic appearance of red and blue high-saturation pixels in multiple consecutive frames, forming a time sequence of on and off states.

[0061] 3. The timing analysis module performs normalized autocorrelation calculation on the flicker sequence of the most recent frames to obtain significant peak values ​​in the range of 1Hz to 4Hz, and outputs a task confidence score higher than the threshold.

[0062] 4. If the current green light direction is inconsistent with the direction from which the ambulance is coming, the state machine will switch to special vehicle priority mode after clearing the yellow light and all-red light, so that the ambulance direction can be quickly cleared.

[0063] Implementation results: The system can automatically determine that an ambulance is performing an emergency mission based solely on video streams, and promptly trigger priority passage while maintaining safe switching at intersections.

[0064] Example 2: False Alarm Suppression in Non-Operating Police Cars and Complex Light Environments 1. In a nighttime scene, a vehicle with police markings enters the intersection area, but its warning lights do not flash at the standard frequency, and there are only occasional reflections and changes in ambient lighting.

[0065] 2. Although the vehicle appearance detection module can identify that the target belongs to the special vehicle category, the HSV color detection output of the local area does not form a stable bright and dark cycle sequence.

[0066] 3. The autocorrelation analysis results do not contain any significant peaks within the effective frequency band, and the peak amplitude is also lower than the minimum confidence threshold. Therefore, the system determines it to be in a non-task execution state.

[0067] 4. Since the dual conditions of task status and confidence level are not met, the signal control module maintains the original normal timing and does not cause additional disturbance to the passage of other vehicles.

[0068] Implementation results: The system can effectively distinguish between the two different concepts of "special vehicle identity" and "performing an emergency mission", avoiding traffic disturbances caused by mistakenly triggering the priority mode.

[0069] Example 4 This application also provides a terminal device for implementing the steps of the above-described special vehicle task status identification method, or the steps of the above-described special vehicle task status identification method. The terminal device includes a processor, a communication interface, a memory, and a communication bus. The processor, communication interface, and memory communicate with each other via the communication bus. A communication control program is stored in the memory and can run on the processor. When executed by the processor, the communication control program implements the steps of the above-described special vehicle task status identification method. The processor can call logical instructions in the memory. These logical instructions can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0070] Example 5 This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for identifying the mission status of a special vehicle.

[0071] Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part 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 of the various embodiments of the present invention. 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.

[0072] The common English terms or letters used in this invention for clarity of description are for illustrative purposes only and are not limiting interpretations or specific uses. They should not be used to limit the scope of protection of this invention based on their possible Chinese translations or specific letters.

[0073] It should also be noted that in this article, relational terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

Claims

1. A method for identifying the mission status of special vehicles, characterized in that, Includes the following steps: S1. Acquire road video data for special vehicle detection, assign a unique trajectory identifier to each special vehicle and continuously track it to generate special vehicle detection results; S2. For each of the trajectory identifiers, extract the corresponding warning light image of the special vehicle frame by frame from the special vehicle detection result and perform color detection to obtain the on / off state of each frame of the warning light image to form a flashing history sequence. S3. Perform autocorrelation analysis on the flickering history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency; S4. For each trajectory identifier, if the peak amplitude reaches a preset peak amplitude threshold and the frequency is between 1Hz and 4Hz, the corresponding special vehicle is identified as being in a mission state.

2. The method for identifying the mission status of special vehicles according to claim 1, characterized in that, In step S1, special vehicles are detected in the road video data based on the YOLO convolutional neural network; and multi-target continuous tracking is performed on each detected special vehicle based on the IoU matching algorithm.

3. The method for identifying the mission status of special vehicles according to claim 1, characterized in that, In step S2, the process of extracting the warning light image of the corresponding special vehicle includes: Based on the detection results of the special vehicle, obtain the current frame image containing the special vehicle and the coordinates of the detection box; In the current frame image, a preset area corresponding to the coordinates of the detection box is cropped to become the warning light image. The preset area is the top preset ratio area in the coordinates of the detection box.

4. The method for identifying the mission status of special vehicles according to claim 1, characterized in that, In step S2, the process of performing color detection on the warning light image includes: The warning light image is converted into a processing image that includes at least chroma information and saturation information, wherein the chroma information includes red and blue; Set a red threshold range, a blue threshold range, and a saturation threshold, and select the pixels in the image to be processed that satisfy at least one of the red threshold range or the blue threshold range and simultaneously satisfy the corresponding saturation threshold as target pixels; The proportion of the target pixel in the image to be processed is calculated. When the proportion reaches a preset lighting threshold, a true value is output; when the proportion does not reach the preset lighting threshold, a false value is output, so as to obtain the on / off state of the warning light image.

5. The method for identifying the mission status of a special vehicle according to claim 4, characterized in that, In step S3, the process of performing autocorrelation analysis on the flicker history sequence corresponding to each trajectory identifier to obtain the corresponding peak amplitude and frequency includes: By mapping true values ​​to +1 and false values ​​to -1, each of the aforementioned flashing history sequences is mapped to a first numerical sequence; Subtract the mean of the first numerical sequence from all the numbers in the first numerical sequence to obtain the second numerical sequence; The autocorrelation function of the second numerical sequence is calculated, and peak search is performed within the search interval to obtain the corresponding peak amplitude and frequency. The search interval is [min_lag, max_lag], where min_lag = max(1, int(fps / 8)), max_lag = min(N-1, int(2fps)), int is the floor function, fps is the sampling rate of the road video data, and N is the number of sequences in the flashing history sequence.

6. The method for identifying the mission status of a special vehicle according to claim 5, characterized in that, Step S4 also includes: When the peak amplitude is below 0.3, the corresponding special vehicle is identified as not in a mission state; When the peak amplitude is not less than 0.3, calculate the frequency of the second numerical sequence; When the peak amplitude reaches 0.75 and the frequency is between 1Hz and 4Hz, the corresponding special vehicle is identified as being in a mission state.

7. The method for identifying the mission status of a special vehicle according to claim 2, characterized in that, The process of performing multi-target continuous tracking of each detected special vehicle based on the IoU matching algorithm includes: Construct the current trajectory tracking pool: Construct a set of currently active trajectories in the tracking pool. Each trajectory includes the trajectory identifier, detection box coordinates, consecutive lost frames, and the flickering history sequence corresponding to the trajectory identifier. Detection confidence level distinction: Determine the detection confidence level of the special vehicle detection result in the current frame, and record the special vehicle detection result with a detection confidence level of not less than 0.5 as a high confidence detection result, and record the result with a detection confidence level of less than 0.5 as a low confidence detection result; Perform high-confidence matching: perform IoU matching between the high-confidence detection results and the trajectories in the tracking pool; if the matching is successful, update the corresponding flashing history sequence. Perform low-confidence matching: perform IoU matching between the low-confidence detection results and the trajectories that did not match in the high-confidence matching; if the match is successful, update the corresponding flashing history sequence. Perform new trajectory creation and invalid trajectory cleanup: create new trajectories for high-confidence detection results that still do not match after the high-confidence matching ends; increment the number of consecutive lost frames of the trajectory that still does not match after the low-confidence matching ends in the tracking pool by 1; when the number of consecutive lost frames exceeds a preset upper limit, remove the corresponding trajectory.

8. A special vehicle mission status recognition system, characterized in that, include: The camera module is used to acquire road video data; An edge computing module is used to execute a special vehicle mission status recognition method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of a special vehicle mission status identification method according to any one of claims 1-7.

10. A traffic signal control method for special vehicles, characterized in that, First, execute the special vehicle mission status recognition method according to any one of claims 1-7; When a special vehicle is on a mission and the light for the direction of origin of the special vehicle is green, the current green light time shall be maintained or extended to allow the special vehicle to pass. When a special vehicle is on a mission and the light for the direction from which the special vehicle originates is not green, a safety clearance is first performed, and then the light for the direction from which the special vehicle originates is set to green, while the light for the other directions is set to red, so that the special vehicle can pass.

Images