An LED street lamp unmanned aerial vehicle inspection method and system based on artificial intelligence

Abstract

The application discloses an LED street lamp unmanned aerial vehicle inspection method and system based on artificial intelligence. The method comprises the following steps: acquiring a road lighting video collected by an unmanned aerial vehicle, frame extraction at a preset interval and quality calculation; adopting a target detection model to detect a street lamp target, and selecting to enable multi-target tracking according to needs; performing cross-frame association based on object identification or detection frame similarity clustering to form a lamp cluster; performing multi-scale cropping and enhancement on the lamp cluster image, and then uniformly sampling the cropped image to obtain an evidence image sequence; loading support samples and prompt word templates, inputting the evidence image sequence and the support samples after assembly into a visual large model to obtain a structured return; and performing post-processing on the structured return, including checking field integrity, calculating confidence and rectifying according to business rules to obtain a final determination result. The application realizes low-miss detection, low-misjudgment and explainable automatic inspection of street lamps in a complex night scene, and can automatically report abnormalities.

Description

Technical Field

[0001] This invention relates to the field of urban road lighting operation and maintenance and computer vision / multimodal intelligent analysis technology, specifically to an AI-based unmanned aerial vehicle (UAV) inspection method and system for LED streetlights. This invention also relates to electronic devices and storage media for implementing the above method and system. Background Technology

[0002] With the rapid pace of urbanization, the number of road lighting facilities has increased dramatically. The stable operation of streetlights is crucial for ensuring nighttime traffic safety and improving urban security. Currently, streetlight inspection mainly relies on manual nighttime patrols or vehicle-mounted assisted patrols. This model suffers from drawbacks such as high labor costs, low efficiency, strong subjectivity, difficulty in achieving full coverage, and significant safety hazards during nighttime operations. In recent years, with the development of drone technology and artificial intelligence, using drones equipped with cameras for automated inspections has become a trend.

[0003] However, drone video street light inspection in complex nighttime scenarios faces a series of severe technical challenges that existing technical solutions cannot adequately address.

[0004] First, the complexity of the nighttime visual environment is a major obstacle. Nighttime lighting conditions are poor, with interference from various strong light sources such as car headlights, shop signs, and reflections, coupled with rain, fog, camera shake, and obstructions. This makes solutions based on traditional image processing or simple deep learning models highly susceptible to false positives and false negatives. For example, car headlights or reflective points in the background may be misjudged as lit, while a normal streetlight may be misjudged as off due to the shooting angle or obstruction. Related patents (such as CN119672629A) also explicitly point out that outdoor video scenes are affected by changes in lighting, wind, rain, day and night cycles, and strong light, requiring the discrimination model to have strong adaptability and anti-interference capabilities.

[0005] Secondly, existing technical solutions have significant shortcomings in terms of robustness and interpretability in street light positioning and status determination. By reviewing and analyzing similar publicly available technologies, the following main limitations can be summarized:

[0006] 1. Chinese Invention Patent Publication No. CN119672629A (Invention Title: An Abnormal Streetlight Detection System and Method Based on YOLOv8 Model): This paper proposes to use YOLOv8 to locate streetlight areas in surveillance images and perform multiple anomaly detections and voting judgments on multiple images from the same time period. This scheme mainly relies on "multiple identifications + voting," failing to highlight robust cross-frame association of the same streetlight, interpretation of evidence fields, and closed-loop mechanisms constrained by large model prompt words. It also lacks interpretability in the face of strong background interference at night.

[0007] 2. Chinese Invention Patent Publication No. CN115512229A (Invention Title: Streetlight Fault Detection Method, Device, Electronic Equipment, and Storage Medium): This method acquires nighttime road images and high-precision map data through roadside equipment, preprocesses them to obtain bright spot areas, and then combines them with the map to determine the streetlight area and derive the fault result. This solution relies on "bright spots" and "map streetlight data," and is easily affected by background lighting; when the drone's perspective or altitude changes, or the map is incomplete, the adaptation cost is high.

[0008] 3. Chinese Invention Patent Publication No. CN121074808A (Invention Title: Indicator Light On / Off Recognition Method, System, and Medium Based on Large and Small Model Collaboration): This method trains a small model to locate and crop indicator light image blocks, then inputs the cropped image and prompt words into a multimodal large model to output the on / off status. This solution targets "indicator lights" as the primary object, failing to address engineering challenges in drone videos such as "small target size, jitter, occlusion, and cross-frame association of the same light," and also neglecting the importance of automatic reporting loops and the stability of the proxy / gateway.

[0009] The existing solutions mentioned above share the following shortcomings:

[0010] 1. Lack of robust cross-frame correlation. Most schemes rely on single-frame or simple multi-frame voting, failing to establish a reliable evidence sequence for the same street light in different video frames, making the judgment results susceptible to accidental occlusion, glare, or jitter.

[0011] 2. Poor interpretability, lack of supporting evidence fields for the judgment results, difficulty in distinguishing between "confirmed as off" and "cannot be confirmed due to interference / obstruction", resulting in a high false alarm rate, especially the high-risk error of misjudging on lights as off;

[0012] 3. The project has not formed a closed loop. The complete link from video acquisition, target association, status determination to automatic notification has not been established. There is a lack of consideration for necessary production environment mechanisms such as network proxy, timeout retry, and structured output constraints.

[0013] Therefore, there is an urgent need in this field for a smart street light inspection method that can cope with complex nighttime environments, has high robustness, strong interpretability, and can achieve automated closed-loop processing. Summary of the Invention

[0014] To overcome the technical problems existing in the prior art, such as unstable cross-frame association of the same light, poor interpretability of judgment in complex nighttime backgrounds, insufficient control over misjudgments, and lack of an engineering closed loop from video acquisition to automatic notification, this invention proposes an AI-based unmanned aerial vehicle (UAV) inspection method and system for LED streetlights. The core of this invention lies in: by integrating lightweight target detection and cross-frame association clustering, the detection boxes of the same physical streetlight in different video frames are aggregated into the same light cluster to form a stable evidence sequence; multi-scale cropping and image enhancement are used to construct the evidence image sequence, and combined with the structured output constraints of the Visual Large Model (VLM), an interpretable judgment result containing streetlight status, confidence level, and evidence fields is obtained; then, the judgment result is corrected and recalibrated through business rules, generating hierarchical alarms and automatically notifying the operation and maintenance system, thereby achieving a closed-loop intelligent inspection of nighttime road streetlights with low missed detections, low misjudgments, interpretability, and traceability.

[0015] Therefore, the first objective of this invention is to provide an AI-based method for inspecting LED streetlights using unmanned aerial vehicles (UAVs), which includes the following steps: Acquire road lighting video captured by drone; The road lighting video is sampled at preset time intervals to obtain a candidate frame set; For each frame image in the candidate frame set, a target detection model is used to detect street light targets to obtain detection boxes. Multi-target tracking is performed on the detection boxes to obtain the object identifiers of each detection box. The detection boxes are aggregated based on the object identifier, or clustered based on the similarity between the detection boxes when the object identifier is missing, and the detection boxes of the same physical street light are associated across frames to form a light cluster; For each light cluster, acquire multiple frames of images corresponding to the detection box associated with the light cluster, and perform multi-scale cropping to form a cropped image. The cropped image retains at least the light core region of the light head and the context region including the light arm, pole, or surrounding road surface. The cropped images within the light cluster are sampled uniformly over time, ensuring that the number of samples does not exceed the preset maximum number of images per light. Low-quality frames are removed or their weight in the calculation is reduced based on image quality indicators to obtain the evidence image sequence. A request to invoke a visual big model is generated based on the evidence image sequence and input into the visual big model. The visual big model performs a preset mode judgment based on the request and outputs a structured return. The structured return includes at least the street light status and multiple predefined evidence fields. The structured return is post-processed, and the post-processing includes at least executing business rule corrections to obtain the final judgment result.

[0016] Preferably, the step of performing multi-target tracking on the detection boxes to obtain object identifiers for each detection box, and then performing similarity clustering of the detection boxes based on the object identifiers or the detection boxes themselves, includes: When multi-target tracking outputs object identifiers, the detection boxes are aggregated into light clusters according to the object identifiers; When the detection box does not have an object identifier, clustering is performed based on the condition that the intersection-union ratio of the detection box and the light cluster representative box is not less than a preset threshold and the minimum number of votes is met.

[0017] Preferably, the multi-scale cropping includes: Basic clipping, edge-expanding clipping, and context-based clipping, with edge-expanding clipping and context-based clipping using different expansion ratios.

[0018] Preferably, the predefined evidence fields include at least one of the following five: Visibility of the light source core, visibility of the dark area of ​​the light source, target visibility, background interference level, and timing consistency.

[0019] Preferably, the determination of the preset mode includes a single-stage mode or a two-stage mode; the two-stage mode includes: The first stage determines whether the street light is ON. If the output is ON, the status result is output directly. If the output is NOT_ON, the second stage is triggered to further distinguish between OFF and UNCERTAIN status.

[0020] Preferably, the business rule correction includes: If the visual model determines that the street light is OFF, but the visibility of the light source in the evidence field is YES, then it will be forcibly corrected to ON. If the visual model determines that the street light status is UNCERTAIN and simultaneously satisfies the following conditions: dark area visibility of the light head is YES, light head visibility is YES, background interference is NO, and temporal consistency is YES, then it is downgraded to OFF; otherwise, it remains UNCERTAIN and a re-inspection suggestion is generated.

[0021] Preferably, after obtaining the final determination result, at least one of the following is also included: Based on the final determination result, a tiered alarm is generated and automatically notified to the operation and maintenance system; A visual review page is generated based on the final judgment result, and the final judgment result and the index of the evidence image sequence are stored in the database.

[0022] The second objective of this invention is to provide an AI-based LED street light drone inspection system, used to implement any one of the methods described in an AI-based LED street light drone inspection method, comprising: The drone data acquisition module is used to acquire video of road lighting. The frame sampling module is used to extract frames from the video at preset time intervals and calculate quality scores for gating judgment. The detection and tracking module is used to detect street light targets in each frame of the image, perform multi-target tracking on the detection boxes, and output the object identifiers of each detection box; The cross-frame association clustering module is used to aggregate detection boxes based on existing object identifiers, or to cluster them based on the similarity between detection boxes, and to associate detection boxes of the same physical street light into light clusters across frames; The cropping and enhancement module is used to perform multi-scale cropping and image enhancement on multiple frames of images corresponding to each light cluster to form a cropped image. The sampling module is used to uniformly sample the cropped image over time and remove or downweight low-quality frames according to quality indicators to obtain the evidence image sequence. The visual large model determination module is used to call the visual large model to perform structured determination and obtain structured return. The post-processing module is used to verify, calculate confidence, and correct business rules for the structured results returned by the large visual model, so as to obtain the final judgment result.

[0023] A third objective of this invention is to provide an electronic device, which is an edge computing device or a cloud server; the electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor being used to execute the computer program to implement corresponding steps in an AI-based unmanned aerial vehicle (UAV) inspection method for LED streetlights.

[0024] The fourth objective of this invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements corresponding steps in an AI-based unmanned aerial vehicle (UAV) inspection method for LED streetlights.

[0025] The beneficial effects of this invention are as follows:

[0026] 1. Achieving stable cross-frame association of the same streetlight, significantly reducing missed detections and detection fragmentation: This invention outputs object identifiers through YOLO detection and multi-target tracking (supporting BoT-SORT or ByteTrack), or employs a clustering method based on IoU threshold and minimum vote count in frame-sparse sampling scenarios to aggregate detection boxes of the same physical streetlight in different video frames into the same light cluster, forming a cross-frame evidence sequence. This mechanism effectively solves the problems of detection box drift and missed detection caused by drone perspective changes, jitter, and occlusion. Drawing on the core idea of ​​ByteTrack to "associate almost all detection boxes," it reduces target loss and trajectory fragmentation, significantly improving the stability and recall rate of the same-light association, and providing a reliable evidentiary basis for subsequent state determination.

[0027] 2. Enhanced robustness of judgment in complex nighttime environments, effectively controlling the risk of misjudgment: This invention addresses complex scenarios such as nighttime lighting changes, strong light interference, rain, and fog by employing multi-scale cropping (simultaneously outputting narrow cropping of the focused light head and wide cropping including the light arm, pole, and surrounding dark areas) combined with image enhancement techniques such as CLAHE and Gamma correction. This enables the large visual model to simultaneously acquire evidence of the light head's luminous core and surrounding illumination. Furthermore, through the design of evidence fields (including light head visibility, luminous core, halo, surrounding illumination level, and background interference), it explicitly distinguishes between "confirmed as off" and "cannot be confirmed due to interference / occlusion." Combined with business rule correction (e.g., when the VLM judges it as OFF but there are ≥2 ON evidence items, it forces correction to ON), it significantly reduces the high-risk error of misjudging a lit light as off, improving the credibility of the judgment results.

[0028] 3. Enhancing the interpretability and traceability of judgment results: This invention employs structured output constraints (JSON mode or JSON Schema) of a large visual model, mandating standardized JSON results that include street light status (ON / OFF / UNCERTAIN), confidence level, and fine-grained evidence fields. Each judgment result is accompanied by evidence fields, explanations of the reasons, and an index of the images used, facilitating subsequent manual review, auditing, and model iteration. Compared to the "black box" voting judgment of existing technologies, this invention achieves interpretability and traceability of the judgment process, providing a transparent basis for operation and maintenance decisions.

[0029] 4. Forming a complete engineering closed loop from video acquisition to automatic notification: This invention constructs an end-to-end processing flow covering frame sampling, detection and tracking, cross-frame clustering, cropping and enhancement, VLM judgment, rule correction, alarm classification, and automatic notification. A hybrid deployment architecture, combining lightweight detection and cropping at the edge and VLM judgment via cloud access, along with engineered support for network proxies (HTTP / SOCKS), timeouts, and retry mechanisms, ensures the system's stability and availability in the production environment. Finally, the judgment results are automatically mapped to graded alarms (e.g., P0 light-out alarm, P1 re-inspection task, P2 manual review), and pushed to the operation and maintenance work order system, along with supporting screenshots and location information. This achieves an automated closed loop of "discovery—judgment—notification—work order dispatch," significantly reducing the cost of manual night patrols and reviews.

[0030] 5. Reduced reliance on prior information such as high-precision maps and strong generalization ability: Compared with existing solutions that rely on "highlights + high-precision maps" (such as CN115512229A), this invention does not require the pre-construction of high-precision street light maps. Instead, it extracts street light evidence directly from video through detection, tracking, and cross-frame correlation. This allows the invention to quickly adapt to inspection tasks in different cities, with different street light types, and with different drone flight altitudes and perspectives, resulting in low deployment costs and strong generalization ability.

[0031] 6. Controlling the cost of large model calls and ensuring project economy: This invention controls the number of input images per lamp by uniformly sampling over time (max_images_per_lamp), and performs size compression and quality screening on the cropped images. This effectively controls the number of image tokens and the cost of calling the large visual model while retaining key evidence. Simultaneously, a two-stage decision-making process (first determining ON, then OFF / UNCERTAIN if not ON) reduces unnecessary fine-grained decision calls, balancing decision quality and economy.

[0032] In summary, this invention has achieved significant improvements over existing technologies in terms of recall rate, false positive control, interpretability, engineering closed-loop integrity, and deployment generalization capability for street light inspection. Attached Figure Description

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

[0034] Figure 1 This is a flowchart illustrating an AI-based unmanned aerial vehicle (UAV) inspection method for LED streetlights according to the present invention.

[0035] The accompanying drawings have illustrated specific embodiments of the invention, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the invention in any way, but rather to illustrate the concept of the invention to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without inventive effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0037] Terminology Explanation

[0038] BoT-SORT Tracker: BoT-SORT (Boosted Online Tracking with SORT) is an advanced multi-object tracking algorithm. Its core lies in fusing motion information and appearance features, and introducing Camera Motion Compensation (CMC) technology and a more accurate Kalman filter state vector. This algorithm improves the localization accuracy of the target box by reconstructing the state vector of the Kalman filter (directly predicting the width and height of the bounding box, rather than the aspect ratio in traditional methods). Simultaneously, the camera motion compensation mechanism calculates the affine transformation matrix through feature point matching, effectively eliminating interference from camera motion and significantly improving tracking stability in dynamic camera scenarios. BoT-SORT achieved leading tracking performance on the MOT17 and MOT20 test sets of MOTChallnge (MOT17: 80.5 MOTA, 80.2 IDF1).

[0039] BoT-SORT is suitable for tracking tasks that require high tracking accuracy and complex motion scenarios (such as frequent changes in the drone's viewpoint and direction).

[0040] ByteTrack Tracker: ByteTrack is a concise and efficient multi-object tracking algorithm whose core idea is to "associate almost every detection box." Unlike traditional tracking algorithms that only retain high-confidence detection boxes, ByteTrack employs a two-stage association strategy: the first stage associates high-confidence detection boxes with existing trajectories; the second stage associates the remaining low-confidence detection boxes with unmatched trajectories, effectively recovering the true targets whose confidence has decreased due to occlusion, blurring, etc., reducing missed detections and trajectory fragmentation. This algorithm maintains high real-time performance while achieving a breakthrough of 80 MOTA on the MOT17 dataset for the first time. ByteTrack is suitable for scenarios with high real-time requirements (such as edge device deployment) and performs exceptionally well in dense environments or scenarios with partial occlusion.

[0041] CLAHE (Contrast-Limited Adaptive Histogram Equalization): A local contrast enhancement algorithm. It divides the image into several small blocks, performs histogram equalization on each block independently, and suppresses noise amplification by limiting the contrast magnification factor, which can effectively improve the contrast between light sources and the background in low-light images at night.

[0042] Gamma correction: A non-linear brightness adjustment method that adjusts the brightness distribution of an image through a power-law transformation (output pixel value = input pixel value raised to the power of γ). When γ < 1, the dark areas of the image are brightened; when γ > 1, the bright areas are darkened. In nighttime street light inspections, correction with γ < 1 is commonly used to enhance details in dark areas.

[0043] Lightweight denoising: It uses low-computation-complexity filtering algorithms (such as Gaussian filtering, median filtering or bilateral filtering) to remove sensor noise, compression artifacts and other interference in the image, while preserving edge information as much as possible, which is suitable for real-time edge processing.

[0044] Sharpening: Filtering operations that enhance image edges and details (such as Laplacian sharpening and unsharpening masks) make the lamp head outline and the boundary of the light-emitting core clearer, which helps the large visual model to accurately identify the street light status.

[0045] Example 1

[0046] To better understand the concept of the AI-based LED street light drone inspection method of this invention, this embodiment uses a routine nighttime (20:00–23:00) drone inspection of a main urban road as an example to illustrate the entire process of the method. In this embodiment, the drone is equipped with a visible light camera and flies along a preset route to collect road lighting video. The deployment method is "edge + cloud hybrid": the edge-side GPU box is responsible for YOLO inference and pruning, while the cloud is responsible for visual large model (VLM) judgment and alarm push.

[0047] This invention provides an artificial intelligence-based method for unmanned aerial vehicle (UAV) inspection of LED streetlights, such as... Figure 1 As shown, it includes the following steps:

[0048] S1, acquire road lighting video collected by drone.

[0049] The drone conducts inspection flights along a preset route, carrying a visible light camera to collect road lighting video. During the data collection, the drone's gimbal employs stable control and night scene exposure strategies to ensure high-quality nighttime video. The video encoding format, resolution, and frame rate are set according to the actual equipment configuration, and metadata such as GPS coordinates, timestamps, and flight attitude are recorded for each frame or its corresponding frame. The video can be uploaded to the edge processing node via a real-time transmission link, or stored on an onboard storage card for batch uploading after the task is completed.

[0050] In this embodiment, the inspection scenario is a routine drone inspection of a main road in a city at night (20:00–23:00).

[0051] S2, extract frames from the road lighting video at preset time intervals to obtain a candidate frame set.

[0052] After receiving video at the edge, candidate frames are extracted according to preset sampling parameters to obtain a candidate frame set. The sampling parameters include: start_sec: Represents the time offset from the start of the video frame extraction, in seconds; duration_sec: Indicates the length of time from the start point, in seconds; every_sec: indicates how many seconds are between each frame; max_frames: Represents the maximum number of frames to extract, used to control computational costs.

[0053] A quality score is calculated for each image in the candidate frame set. The quality score includes at least one of blurriness, overexposure ratio, and number of bright connected components. Low-quality frames are marked based on the quality score, and their weight is reduced in subsequent sampling or confidence calculation of evidence image sequences. Preferably, at least two or more indicators are combined for calculation.

[0054] Preferably, let the blurriness of the i-th frame be Bi, the overexposure ratio be Ei, and the number of bright connected components be Hi. Here, blurriness reflects the image sharpness, overexposure ratio reflects the proportion of overexposed areas in the image, and the number of bright connected components reflects the degree of background highlight interference in complex nighttime scenes. Since the dimensions of each indicator are different, they can be normalized first to obtain bi, ei, and hi, and then the overall quality score q_score(i) of the frame can be calculated. For example, the overall quality score can be expressed as: q_score(i)=wb•(1-bi)+we•(1-ei)+wh•(1-hi) Where wb, we, and wh represent the weighting coefficients corresponding to blur level, overexposure ratio, and number of bright connected components, respectively, and satisfy wb + we + wh = 1. According to the above definition, the higher the blur level, the lower the quality score; the higher the overexposure ratio or the more obvious the background highlight interference, the lower the quality score.

[0055] Furthermore, quality gating of candidate frames can be performed by combining individual threshold judgment and comprehensive quality score judgment. For example, when the blurriness Bi of a frame is lower than the preset blurriness threshold Tblur, the overexposure ratio Ei is higher than the preset overexposure ratio threshold Tover, or its comprehensive quality score Qi is lower than the preset quality threshold Tq, the frame can be marked as a low-quality frame.

[0056] As an example, the blur threshold Tblur can be set to 0.3, the overexposure ratio threshold Tover to 0.4, and the overall quality score threshold Tq to 0.5; the weighting coefficients can be wb=0.4, we=0.3, and wh=0.3. It should be noted that the above values ​​are only examples and can be adjusted according to image acquisition conditions and inspection accuracy requirements in actual applications.

[0057] The low-quality frames do not need to be directly discarded, but are retained and their participation weight is reduced in subsequent evidence summarization, evidence image sampling, state determination or confidence fusion processes, so as to avoid losing potentially valid evidence due to insufficient quality of a single frame.

[0058] The quality scores, gating tags, and corresponding timestamps of all candidate frames can be written to a quality gating log file for auditing, backtracking, and subsequent parameter optimization.

[0059] After frame extraction is completed, a candidate frame set F is output. Each frame in the candidate frame set F contains a frame number, timestamp, image data and its quality score.

[0060] In this embodiment, the sampling parameters are set as follows: start_sec=0, duration_sec=600, every_sec=2, max_frames=300. For each extracted frame, quality scores are calculated, including blurriness, overexposure ratio, and number of highlighted connected components. Low-quality frames are marked but retained, and the gating results are written to a quality gating log file.

[0061] S3, for each frame image in the candidate frame set, a target detection model is used to detect street light targets, and detection boxes are obtained. Multi-target tracking is performed on the detection boxes to obtain the object identifiers of each detection box.

[0062] For each frame in the candidate frame set F, the trained YOLO object detection model is called to detect streetlight targets. Detection parameters include: Weights: Specifies the path to the model weights file; Device: Specifies the computing device (such as CPU or GPU number); imgsz specifies the size of the input image; conf specifies the detection confidence threshold. iou specifies the IoU threshold for nonmaximum suppression (NMS); class_ids: Specifies the target category to be detected (e.g., only detect street light category).

[0063] Select and enable multi-target tracking mode as needed, using either BoT-SORT or ByteTrack trackers, and configure relevant tracking parameters (including track_high_thresh, track_low_thresh, new_track_thresh, track_buffer, etc.) to obtain the cross-frame tracking identifier (track_id) for each detection box. Output a list of detection boxes for each frame, where each detection box includes bounding box coordinates, confidence score, and, if tracking is enabled, a tracking ID.

[0064] In this embodiment, the YOLO model parameters are set as follows: weights= / models / yolo_streetlamp_best.pt, device="0", imgsz=960, conf=0.25, iou=0.5, class_ids=null. The ByteTrack tracker is enabled, configured with track_high_thresh=0.4, track_low_thresh=0.1, new_track_thresh=0.4, and track_buffer=30. A list of detection boxes is output for each frame, with each box containing its bounding box coordinates, confidence score, and tracking ID.

[0065] S4. Aggregate the detection boxes based on the object identifier, or cluster them based on the similarity between the detection boxes when the object identifier is missing, and associate the detection boxes of the same physical street light across frames to form a light cluster.

[0066] Based on the detection box sequence output in step S3, detection boxes belonging to the same physical street light are aggregated into a light cluster using one of the following two methods, and a unique lamp_id is assigned to each light cluster:

[0067] Method 1 (Tracking Priority): When multi-target tracking outputs object identifiers, the detection boxes are aggregated into lights according to the object identifiers.

[0068] Method 2 (Frame-by-Frame Clustering): When no object identifier is available, clustering is performed based on the condition that the intersection-union ratio (IoU) between the detection box and the representative box of the light cluster is not less than a preset threshold and the minimum number of votes is met. Specifically, if there is no tracking ID or tracking is interrupted, a clustering method based on the positional similarity of the detection boxes is used. For each detection box, the IoU with the existing representative box of the light cluster is calculated. If the IoU is not less than the preset threshold cluster_iou, the detection box is merged into the cluster, and the representative box of the cluster is updated (e.g., using the mean or median). If the IoU is less than the threshold, a new light cluster is created. At the same time, a minimum number of cluster votes min_cluster_votes is set. Light clusters with fewer than this threshold of detection boxes are discarded to filter out isolated false detections.

[0069] Output the lamp cluster registry, which records information such as the representative box corresponding to each lamp_id, the frame number it contains, and the timestamp list.

[0070] In this embodiment, ByteTrack has been enabled and tracking IDs have been obtained in step S3. Therefore, the tracking IDs are used directly for merging, resulting in 156 light clusters. For the 9 lights with tracking interruptions, IoU clustering is used to supplement the merging, with cluster_iou=0.30 and min_cluster_votes=2. This successfully merges the interrupted tracks, resulting in 162 light clusters. The light cluster registry is written to lamp_registry.json.

[0071] S5. For each light cluster, acquire multiple frames of images corresponding to the detection box associated with the light cluster, and perform multi-scale cropping to form a cropped image. The cropped image retains at least the core light-emitting area of ​​the light head and the context area including the light arm, pole, or surrounding road surface.

[0072] Specifically, for each light cluster, multi-scale cropping and image enhancement are performed based on each frame of image it records and the corresponding detection box to generate a sequence of evidence images.

[0073] The multi-scale cropping includes basic cropping, edge-expansion cropping, and context-based cropping, where edge-expansion cropping and context-based cropping use different expansion ratios, as detailed below:

[0074] 1. Basic trimming: Trim directly according to the detection frame.

[0075] 2. Edge Expansion and Cropping: The detection box is expanded and cropped according to a preset expansion ratio `crop_padding`. Specifically, the original detection box width is denoted as `bw = x2 - x1`, and the original detection box height is denoted as `bh = y2 - y1`. The horizontal expansion in pixels is `px = round(bw × crop_padding)`, and the vertical expansion in pixels is `py = round(bh × crop_padding)`. Based on this, the coordinates of the expanded candidate cropping box are: `x1' = x1 - px, y1' = y1 - py, x2' = x2 + px, y2' = y2 + py`. To prevent the expanded candidate cropping box from exceeding the original image boundary, boundary constraints need to be applied to obtain the final expanded cropping box coordinates: x1" = max(0, min(x1', w - 1)), y1'' = max(0, min(y1', h - 1)), x2'' = max(1, min(x2', w)), y2" = max(1, min(y2', h)). Finally, the expanded cropped image is extracted from the original image according to img[y1":y2", x1":x2"].

[0076] 3. Contextual cropping: Uses a larger scaling factor to include the lamp arm, pole, and surrounding road surface in the cropped image.

[0077] The image enhancement includes at least one or more of the following: CLAHE (Contrast Limiting Adaptive Histogram Equalization, Gamma Correction, Lightweight Denoising, and Sharpening).

[0078] Compress the cropped images to ensure that the size of a single image does not exceed the limits of the visual large model interface (e.g., avoid images larger than 8MB that will be discarded). Record information such as the cropping scale and enhancement parameter version number used for each image.

[0079] Output the evidence image sequence for each light cluster, store it in the specified directory, and generate a cropping index file that records information such as the source frame, cropping scale, compression ratio, and quality score of each image.

[0080] In this embodiment, the expansion ratio of the cropping is set to crop_padding=0.12, and a context crop (expansion ratio 0.30) is generated simultaneously. Each cropped image is compressed to limit the long side to no more than 800 pixels, and the JPEG compression quality is set to 88. CLAHE (parameters clipLimit=2.0, gridSize=8×8) and Gamma correction (γ=0.8) are applied. Approximately 15 evidence images are generated per light cluster, and all images are stored in lamp_crops / <lamp_id> The ` / ` subdirectory contains metadata records from the crop_index.csv index file.

[0081] S6. The cropped images within the light cluster are sampled uniformly over time, ensuring that the number of samples does not exceed the preset maximum number of images per light. Low-quality frames are removed or their weight in the calculation is reduced based on the image quality index, thus obtaining the evidence image sequence.

[0082] To avoid excessive token consumption for the large visual model due to too many input images for a single light (according to the OpenAI Vision Guidelines, multiple images will incur token costs), and to preserve key temporal evidence, cropped images for each light cluster are uniformly sampled over time to form an evidence image sequence. Specifically, for a cropped image sequence corresponding to a given light identifier, images are sorted by timestamp, and a predetermined number (denoted as max_images_per_lamp) of images are evenly selected from beginning to end. During sampling, priority is given to including the first frame, middle frames, last frame, and the frame with the highest quality score to reduce the impact of occasional glare or blurry frames on the judgment.

[0083] In this embodiment, max_images_per_lamp=8 is set. For the light cluster with lamp_id=0032, 8 images are evenly sampled from its 15 cropped images according to the timestamp, including the first frame, the fourth frame, the middle frame, the last frame, and the two frames with the highest quality scores.

[0084] S7. Based on the evidence image sequence, generate a call request for a visual big model and input the visual big model. The visual big model performs a preset mode judgment based on the call request and outputs a structured return. The structured return includes at least the street light status and multiple predefined evidence fields.

[0085] Specifically, a preset support sample and a preset prompt word template are loaded. The evidence image sequence and the support sample are assembled into a request according to the prompt word template. The support sample includes light-on samples and light-off samples. Specifically, the input includes a list of images to be judged, a support sample directory (denoted as support_examples_dir), the number of samples in each class (denoted as support_each_class), and the prompt word template.

[0086] The supporting samples are preferably selected from a set of samples that are similar to the current inspection task in terms of UAV flight altitude, camera focal length, light type, shooting angle and nighttime background complexity. It is also preferred to control the number of supporting samples of each class to not exceed the preset value support_each_class (2 in this embodiment) to reduce the risk of the visual large model forming incorrect priors.

[0087] The processing procedure is as follows: First, select no more than support_each_class example images from the "on" subdirectory (which stores typical lit-up samples) and the "off" subdirectory (which stores typical unlit samples) under the support sample directory, and place them at the beginning of the input image sequence; then attach the multiple images to be judged.

[0088] The predefined evidence fields include at least several of the following five: lamp head luminous core visibility, lamp head dark area visibility, target visibility, background interference level, and temporal consistency. In the output JSON, these five fields correspond to lamp_head_glowing, lamp_head_dark_visible, target_visibility, background_interference, and temporal_consistency in the evidence object, respectively.

[0089] In some implementations, the evidence fields may further include halo_visible and ground_or_nearby_illuminated as extended evidence fields to enhance the attribution of lighting and the expression of evidence for localized illumination. However, in this embodiment, for the sake of simplicity, only the above five core evidence fields are used.

[0090] To ensure that the output of the large visual model is parsable and that the fields are complete, this embodiment, based on the explicit requirement in the prompt to output structured JSON, further sets the response format parameter (response_format) during API calls. This parameter can be selected from the following two methods: using JSON schema ({"type": "json_object"}) to ensure that the model output is a valid JSON object; or using a more stringent JSON Schema schema ({"type": "json_schema", "json_schema":{...}, "strict": true}) to enforce constraints on the type, value range, and mandatory nature of the output fields.

[0091] To ensure that the output of the large visual model is parsable and has complete fields, in some implementations, the response format parameter `response_format` can be set during API calls to constrain the model output to a JSON object or a structured result conforming to a preset JSON schema. In implementations where the response format parameter is not explicitly set, prompt words can also constrain the model output to JSON, and the returned content can be extracted, parsed, normalized, and anomaly handled in the post-processing stage. This embodiment uses prompt words to constrain the output to JSON, and combines regular expression extraction, JSON parsing, and field normalization to complete the structured result processing and form a structured return.

[0092] In some implementations, the response format parameter can be set to the following JSON Schema structure: { "type": "json_schema", "json_schema": { "name": "lamp_review_result", "strict": true, "schema": { "type": "object", "additionalProperties": false, "required": ["state", "confidence", "evidence", "reason"], "properties": { "state": { "type": "string", "enum": ["ON", "OFF", "UNCERTAIN"] }, "confidence": { "type": "number", "minimum": 0.0, "maximum": 1.0 }, "evidence": { "type": "object", "additionalProperties": false, "required": [ "lamp_head_glowing", "lamp_head_dark_visible", "target_visibility", "background_interference", "temporal_consistency" ], "properties": { "lamp_head_glowing": { "type": "string", "enum": ["YES", "NO", "UNKNOWN"] }, "lamp_head_dark_visible": { "type": "string", "enum": ["YES", "NO", "UNKNOWN"] }, "target_visibility": { "type": "string", "enum": ["YES", "NO", "UNKNOWN"] }, "background_interference": { "type": "string", "enum": ["YES", "NO", "UNKNOWN"] }, "temporal_consistency": { "type": "string", "enum": ["YES", "NO", "UNKNOWN"] } } }, "reason": { "type": "string", "minLength": 1 }} } } }

[0093] Based on the aforementioned JSON Schema, the `state` field in the model output is limited to one of ON, OFF, or UNCERTAIN; the `confidence` field is limited to a value between 0.0 and 1.0; the `evidence` field is limited to an object type and includes five mandatory evidence fields: `lamp_head_glowing`, `lamp_head_dark_visible`, `target_visibility`, `background_interference`, and `temporal_consistency`. The values ​​for each evidence field are limited to YES, NO, or UNKNOWN; the `reason` field is limited to a non-empty string; and outputting any undefined additional fields is prohibited. These constraints ensure that the field constraints defined in the prompts are enforced at the interface layer, thereby improving the parsability, consistency, and auditability of the output results.

[0094] The meanings of the evidence fields are as follows: lamp_head_glowing: Used to characterize whether there is clear evidence of light emission from the lamp head itself; lamp_head_dark_visible: This indicates whether the lamp head body can be clearly observed without emitting light; target_visibility is used to characterize whether key parts of the lamp head are clearly visible; background_interference is used to characterize whether the background highlight interference is obvious; temporal_consistency is used to characterize whether the judgments in consecutive screenshots are consistent.

[0095] The evidence field preferably adopts a three-value representation, where UNKNOWN indicates that a clear judgment cannot be made on the corresponding field based on the current image evidence. The field setting is consistent with the logic of judgment and correction based on evidence of lamp head emitting light, visibility of lamp head not emitting light, target visibility, background interference, and cross-frame consistency in existing embodiments.

[0096] The structured output of this step can form an auditable request and response record. The record includes at least the example image used, the image to be judged, the prompt word version number, the response format parameters, and the structured result returned by the model, so as to facilitate subsequent auditing, backtracking, and parameter optimization.

[0097] In this embodiment, the supported sample directory is / data / support_examples, with a sample size of 2 per category. Two images are randomly selected from the "on" subdirectory (filenames on_typical_01.jpg and on_typical_02.jpg), and two images are selected from the "off" subdirectory (filenames off_typical_01.jpg and off_typical_02.jpg). The prompt word template uses the above content and requires the output to include state, confidence, evidence fields (including five subfields: lamp_head_glowing, lamp_head_dark_visible, target_visibility, background_interference, and temporal_consistency, with values ​​of YES / NO / UNKNOWN), and reason.

[0098] The assembled call request is input into the visual large model. In this embodiment, one of the following two determination modes is used to obtain the structured return output of the visual large model, which can be configured according to the actual scenario:

[0099] 1. Single-stage mode: The assembled request (including the example image and multiple images to be judged) is input into the large-scale visual model all at once. The model is required to directly output the final state (ON / OFF / UNCERTAIN) and the corresponding evidence fields, obtaining a structured return. The structured return is preferably in JSON object format. In single-stage mode, the large-scale visual model outputs a JSON object containing state, confidence, evidence, and reason, where: state: The final state, which can be ON, OFF, or UNCERTAIN; confidence: indicates the degree of confidence in the corresponding judgment result; evidence: Represents the set of evidence fields that support the determination of the status; "reason" indicates a brief reason for a judgment.

[0100] The evidence preferably includes at least five fields: lamp_head_glowing, lamp_head_dark_visible, target_visibility, background_interference, and temporal_consistency. The preferred values ​​for each field are YES, NO, or UNKNOWN.

[0101] This mode requires fewer calls and has lower latency, making it suitable for scenarios with good lighting conditions and minimal background interference, or for large-scale, rapid screening tasks that are cost-sensitive.

[0102] 2. Two-stage mode: The first stage determines whether the street light is ON. If the output is NOT_ON, the second stage is triggered to further distinguish between OFF and UNCERTAIN states.

[0103] Specifically, in the first stage, the assembled request (containing a sample image and multiple images to be judged) is input into the visual model. The model is only required to determine whether it is "ON" or "NOT_ON" and obtain a structured return. If the output is ON, the process ends directly. If the output is NOT_ON, the second stage is triggered. The same images are assembled into a request and input into the model again. The model is required to further distinguish between "OFF" and "UNCERTAIN" and provide interpretable evidence such as "the light is visible but not lit," obtaining a structured return. The structured return in the second stage includes the fields of state, confidence, and reason. The state value is OFF or UNCERTAIN, and may further include the evidence field to output interpretable evidence. To ensure that the output results are parsable and the fields are complete, the model output format can be constrained by the response_format parameter during function call, such as JSON mode or JSON Schema mode; or the model output can be constrained by prompt words, and the returned content can be extracted, parsed, and the fields normalized in the post-processing stage to achieve structured output.

[0104] The two-stage mode significantly reduces the risk of misjudging a lit light as an off light by using a two-stage screening process, making it suitable for scenarios with complex backgrounds and frequent strong light interference at night.

[0105] It should be noted that a single request can contain multiple images, but the number of images will be counted in the token and affect billing. Therefore, a reasonable limit should be imposed based on the preset maximum number of images per light.

[0106] In this embodiment, a two-stage decision-making mode is adopted to reduce the risk of misjudgment. An OpenAI-compatible gateway (model: gemini-3-pro-preview) is invoked, and the api_key is configured to be read from environment variables. A timeout of 60 seconds and a maximum of 2 retries are set. Access to the external gateway is via a SOCKS5 proxy (socks5: / / 127.0.0.1:10808). The response format parameters are set to JSON Schema mode, strictly constraining the output field types and value ranges. The first stage (ON determination): Two ON example images, two OFF example images, and eight images to be determined are cropped. Figure 1The input is the same as the output, and the system is required to determine whether it is ON. If the output state is ON and the confidence level is not lower than 0.6, the second stage of further confirmation is triggered. The second stage (OFF / UNCERTAIN determination): is triggered only when the output of the first stage is not ON. The model is called again, and the prompt emphasizes the distinction between "the lamp head is visible but not emitting light (OFF)" and "cannot be confirmed due to interference / obstruction (UNCERTAIN)". In this embodiment, out of 162 lamp clusters, 138 were determined to be ON in the first stage, and 24 entered the second stage, of which 7 were determined to be OFF and 17 were determined to be UNCERTAIN.

[0107] S8, perform post-processing on the structured return, the post-processing including at least executing business rule correction to obtain the final judgment result.

[0108] This step performs post-processing on the structured JSON results returned by the large visual model, including normalization of evidence fields, fusion and recalibration of confidence scores, and correction based on business rules. Finally, it outputs traceable judgment results and generates re-inspection suggestions.

[0109] Upon receiving the JSON returned by the large visual model, the first step is to verify the completeness of the fields, filling in missing fields with the default value "UNKNOWN". Then, evidence fields are normalized and confidence scores are fused. The baseline confidence level c0 is provided by the confidence field output by the model; ON supports the weighted calculation of s_on by the fields lamp_head_glowing, lamp_head_dark_visible, and target_visibility (for example, if all three are YES, then s_on=0.9; if two are YES and one is UNKNOWN, then s_on=0.7). The OFF parameter s_off is calculated by weighting target_visibility=YES, lamp_head_glowing=NO, lamp_head_dark_visible=YES, and low background interference. Low background interference is preferably determined based on the evidence field background_interference. When background_interference=NO, it is considered that the background highlight interference is not obvious, i.e., it belongs to low background interference; when background_interference=YES, it is considered that the background highlight interference is obvious; when background_interference=UNKNOWN, it is considered that the degree of background interference cannot be determined based on the current image evidence, and it is preferred not to directly identify it as low background interference.

[0110] The final confidence level is calculated using the formula: confidence_final = clip(α×c0 + β×max(s_on, s_off), 0, 1) Where α=0.5 and β=0.5. For the UNCERTAIN state, a confidence upper limit is set (e.g., not exceeding 0.6) to reflect conservatism.

[0111] To reduce the high-risk error of misinterpreting a lit light as an off light, this embodiment sets the following business rules for correction: Rule 1 (Forced ON): If the model determines it to be OFF but the visibility of the light head's luminous core in the evidence field is YES, then it will be forcibly corrected to ON.

[0112] Specifically, if the visual big model determines it to be OFF, but lamp_head_glowing=YES, then it is forcibly corrected to ON, confidence_final is set to 0.9, and the reason for correction is recorded as "evidence contradiction, rule correction".

[0113] Rule 2 (UNCERTAIN downgraded to OFF): If the model is judged as UNCERTAIN and simultaneously satisfies the following conditions: dark area visibility of lamp head is YES, lamp head visibility is YES, background interference is NO, and temporal consistency is YES, then it is downgraded to OFF.

[0114] Specifically, if the visual big model determines that it is UNCERTAIN, and simultaneously satisfies lamp_head_dark_visible=YES, target_visibility=YES, lamp_head_glowing=NO, background_interference=NO, and temporal_consistency=YES, then the state is downgraded to OFF, confidence_final is set to 0.65, and the reason for correction is recorded as "Rule downgrade: The lamp head is clearly visible and does not emit light, with no interference".

[0115] Rule 3 (UNCERTAIN Remain): Otherwise, maintain UNCERTAIN and generate a re-inspection recommendation.

[0116] Specifically, if key evidence is missing or conflicting (e.g., target_visibility=NO), the UNCERTAIN state is maintained, and a "re-examination suggestion" is generated (e.g., increase flight altitude, decrease flight speed, or take additional close-up images).

[0117] After the above processing is completed, the final judgment result for each lamp cluster is output and written to the lamp_review.csv file, along with the lamp_data for each lamp cluster. <id>The _parsed.json file is an audit retention file.

[0118] In this embodiment, a total of 24 light clusters entered the second stage. Among them, 7 were determined to be OFF by the visual large model, and 17 were determined to be UNCERTAIN. Correction was performed: 3 light clusters determined to be OFF were forcibly corrected to ON according to rule 1 because evidence showed lamp_head_glowing=YES (actually a misjudgment caused by reflection from distant car lights); 5 light clusters determined to be UNCERTAIN were downgraded to OFF according to rule 2 because they met the conditions of target_visibility=YES, lamp_head_glowing=NO and had no interference; the remaining 12 retained their original determination. The final statistical results are: 141 lights in ON state (138 lights in the original first stage plus 3 lights obtained from OFF correction), 9 lights in OFF state (7 lights in the original OFF state minus 3 lights turned ON plus 5 lights turned OFF from UNCERTAIN), and 12 lights in UNCERTAIN state (17 lights in the original UNCERTAIN state minus 5 lights turned OFF).

[0119] As an optional implementation, after step S8, step S9 is also included, in which a graded alarm is generated based on the final determination result and automatically notified to the operation and maintenance system.

[0120] Based on the final judgment result output in step S8 (including final status, confidence level, evidence fields, geographical location information, etc.), a graded alarm is generated and automatically pushed to the operation and maintenance system, forming a closed loop of "discovery - judgment - notification - dispatch".

[0121] S91 classifies alarm levels into three levels: P0, P1, and P2, based on street light status, confidence level, and historical inspection records.

[0122] Based on street light status, confidence level, and historical inspection records, this embodiment divides the alarm notification load into the following three levels:

[0123] P0 alarm (high priority): Status is OFF with a confidence level of not less than 0.75, or both inspection windows determine it to be OFF. This level triggers an immediate push notification, requiring maintenance personnel to respond and handle it quickly.

[0124] P1 Alarm (Medium Priority): Status is UNCERTAIN and there is a potential anomaly (e.g., temporal_consistency is NO, suspected flickering; or the "re-inspection suggestion" generated in rule 3 of step S9). This level generates a re-inspection task, suggesting adjusting flight parameters (e.g., increasing altitude, decreasing speed) and then taking a new photo.

[0125] P2 Alert (Low Priority): Inconsistent model judgment results (e.g., conflict between single-stage and two-stage results) or severely insufficient evidence. This level is only recorded in the review list for manual spot checks and is not proactively pushed.

[0126] S92, push the alarm level to the instant messaging system, and call the operation and maintenance work order system API to create or update a work order.

[0127] The alarm notification payload includes the following information: street light identifier (lamp_id), geographic location (GPS coordinates, which can be obtained from drone metadata interpolation or by matching the street light GIS database), inspection time window, final status, confidence level, evidence field summary, evidence screenshot URL (multiple keyframe cropped images), original model response hash, model version, and rule correction records (if any). The notification payload is pushed to instant messaging systems such as WeChat Work, DingTalk, or Lark via Webhook, and simultaneously calls the API of the operation and maintenance work order system to create or update work orders and associate media evidence packages.

[0128] S93, based on the final judgment result, generate a visual review product, and combine the original panoramic frame with the multi-scale cropped mosaic to output a review image or short video of each lamp.

[0129] To facilitate rapid review by maintenance personnel, this embodiment also generates visual review products, such as combining the original panoramic frame (with the lamp head positions marked) with multi-scale cropped mosaics to output a review image or short video for each lamp. This product reduces the cost of manual review and can be archived as an attachment to work orders.

[0130] In this embodiment, the final statistical result of step S9 is: 141 lamps in ON state, 9 lamps in OFF state, and 12 lamps in UNCERTAIN state. According to the alarm classification rules:

[0131] Of the 9 OFF lights, 4 have a confidence level of not less than 0.75 (all of which are the original judgment results of keeping OFF in step S7), thus triggering a P0 alarm for 4 lights, which is pushed to the operation and maintenance work order system and @ the on-duty personnel. The remaining 5 OFF lights (downgraded from UNCERTAIN by rule 2, with a confidence level of 0.65) did not reach the P0 threshold and were only recorded in the database.

[0132] Of the 12 UNCERTAIN lights, 4 had a temporal_consistency field of NO (suspected flashing), triggering the P1 re-inspection task and generating re-inspection suggestions (such as reducing flight speed and re-collecting data). The remaining UNCERTAIN lights (8 lights) and all ON lights (141 lights) were only recorded in the database and did not trigger alarm pushes.

[0133] The alarm payload includes street light identification, GPS coordinates (obtained from drone metadata interpolation), and evidence screenshot URLs (four keyframe cropped images for each light). It is pushed to WeChat Work via Webhook, and simultaneously calls the work order system API to automatically create six P0 work orders and assign them to maintenance teams. All alarm events and review deliverables are stored in the database for subsequent traceability and statistics.

[0134] As an optional implementation, after step S8, step S10 is also included, in which a visual review page is generated based on the final judgment result, and the final judgment result and the index of the evidence image sequence are stored in the database.

[0135] This step stores all data generated during the entire inspection process (including raw frame quality gating records, detection tracking results, lamp cluster registry, pruning index, visual large model requests and responses, evidence field normalization results, business rule correction records, final judgment results, and alarm events) into the database, and generates a visual review page for each lamp for operation and maintenance personnel to review and confirm.

[0136] S101, store the final judgment result of the light cluster, the visual large model request and response, the evidence image index, the frame quality gating record and the alarm event into the database.

[0137] All judgment results (final state, confidence level, evidence fields, and rule correction records for each light), original visual model requests and responses (including prompt word versions, image lists, and response JSON), evidence image indexes (cropped image storage paths and source frame information), frame quality gating records (blurriness, overexposure ratio, etc.), and alarm events (alarm level, push status, and work order ID) are stored in a relational database (such as PostgreSQL) or a document database (such as MongoDB). The data tables must include at least: an inspection task table, a light cluster result table, an evidence image table, an alarm event table, and a model call log table.

[0138] S102, generate a visual verification page for each lamp in the lamp cluster. The page includes a panoramic view, a cropped sequence mosaic, a judgment result card, and alarm information.

[0139] To facilitate quick review of abnormal results by maintenance personnel, this embodiment generates a visual review page for each light in the light cluster. This page contains the following:

[0140] Panoramic view: A screenshot of the original video frame with the location of the streetlight marked (select the highest quality frame or the first frame), showing the relative position of the streetlight in the road scene.

[0141] Cropped sequence mosaic: Multiple cropped images arranged in chronological order (such as the max_images_per_lamp images sampled in step S6.1) are stitched together into a large image or arranged horizontally to facilitate observation of the light emission consistency of the lamp head in multiple frames.

[0142] Judgment Result Card: Displays the final status (ON / OFF / UNCERTAIN), confidence level, evidence fields (values ​​of six sub-fields), reason for correction (if any), and re-inspection suggestion (if any). Alarm Information: If the light triggers an alarm, displays the alarm level (P0 / P1 / P2), work order ID, and push time.

[0143] Maintenance personnel can use the web interface to filter P0, P1, or P2 alarms with a single click, manually review the UNCERTAIN results, and change the status to "Confirmed Off", "Confirmed On", or "Requires On-site Verification" after confirmation. All review operations (including reviewer, time, and modification results) are recorded in the database, forming a complete audit chain.

[0144] In this embodiment, all data is stored in a PostgreSQL database. Wherein: The lamp_review table records 162 judgment results (141 lamps ON, 9 lamps OFF, and 12 lamps UNCERTAIN). The alarm_event table records 4 P0 alarms and 4 P1 re-examination tasks; The `model_call_log` table records all requests and responses for the large visual model (a total of 162 × 2 calls, due to the use of a two-stage mode).

[0145] The generated visual verification page is displayed via a web interface. Within 10 minutes of starting work the following day, maintenance personnel confirmed all P0 alarms: all four lights were indeed off, with two of them showing weak illumination due to lampshades obstructing the light, correctly downgraded to OFF by rule two in step S7. For the four P1 re-inspection tasks, the system automatically scheduled a second inspection that evening (adjusting the flight altitude by 10 meters and the speed to 5 m / s). Compared to traditional manual night patrols (requiring two people to complete 12 kilometers in two hours), this embodiment's total inspection time is approximately 18 minutes (12 minutes for edge processing + 6 minutes for cloud VLM calls), improving efficiency by approximately 85%, and all judgment results are traceable and auditable.

[0146] To further verify the technical effectiveness of the present invention, the following comparative experiment was conducted on the same nighttime inspection dataset.

[0147] Experiment 1: Cross-frame light cluster evidence sequence determination vs. single-frame direct determination

[0148] This experiment compares the cross-frame light cluster evidence sequence determination scheme used in this invention with the single-frame direct determination scheme. Evaluation metrics include the false alarm rate for OFF (light off), the recall rate for ON (light on), and the percentage of UNCERTAIN (unable to confirm). The experiment aims to verify that cross-frame association of the detection results of the same physical street light in different video frames to form an evidence image sequence can effectively reduce accidental misjudgments caused by strong nighttime light interference, partial occlusion, motion blur, or momentary jitter, and improve the stable recognition capability of the on / off state. The comparison results are shown in Table 1.

[0149] Table 1 Performance Comparison of Different Decision Schemes

[0150] The slightly higher proportion of UNCERTAIN in the cross-frame scheme is due to its more rigorous marking of uncertain scenarios such as occlusion and strong light interference as UNCERTAIN, rather than forcibly outputting ON / OFF, thereby reducing the risk of misjudgment.

[0151] Experiment 2: Two-phase decision vs. single-phase decision

[0152] This experiment compares the preferred two-stage decision-making scheme of this invention with the single-stage decision-making scheme. Evaluation metrics include the probability of misjudging ON (light on) as OFF (light off), average call latency, and average call cost. The experiment aims to verify that although the two-stage decision-making scheme slightly increases call latency and cost, it can significantly reduce the high-risk error of misjudging ON as OFF, thereby achieving higher engineering reliability in complex nighttime inspection scenarios. The comparison results are shown in Table 2.

[0153] Table 2 Performance and cost comparison of different decision modes

[0154] Experiment 3: Business Rule Correction vs. No Rule Correction

[0155] This experiment compares the business rule-based correction scheme used in this invention with a ruleless correction scheme. Evaluation metrics include final judgment accuracy, manual review and correction rate, and OFF (lights off) false alarm rate. The experiment aims to verify that, based on the structured output of the large visual model, further incorporating evidence fields for business rule correction can effectively reduce evidence-contradictory misjudgments, improve the interpretability and direct handling of the final output, and significantly reduce the workload of manual review and secondary correction. The comparison results are shown in Table 3.

[0156] Table 3. Impact of rule correction on judgment effectiveness

[0157] The three sets of comparative experiments above jointly demonstrate, from the aspects of misjudgment control, result interpretability, and engineering economy, that the present invention has made significant progress compared with the prior art.

[0158] Example 2

[0159] This embodiment provides an AI-based LED street light drone inspection system for implementing the method described in Embodiment 1. The system adopts an "edge + cloud hybrid" deployment architecture, with a lightweight computing module deployed at the edge and a large visual model invocation and post-processing module deployed in the cloud. The system includes the following modules.

[0160] 1. Drone data acquisition module, used to acquire road lighting video.

[0161] This module is used to conduct inspection flights along preset routes on target roads, carrying a visible light camera to collect road lighting video. During the acquisition process, the drone gimbal employs stable control and night scene exposure strategies to ensure nighttime video quality. The video encoding format, resolution, and frame rate are set according to the actual equipment configuration, and metadata such as GPS coordinates, timestamps, and flight attitude are recorded for each frame or the corresponding frame. The video can be uploaded to the edge processing node via a real-time transmission link, or stored in an onboard storage card for batch uploading after the task is completed.

[0162] 2. A frame sampling module is used to extract frames from the video at preset time intervals and calculate quality scores for gating judgment.

[0163] This module receives video uploaded by the drone's acquisition module and extracts frames according to preset sampling parameters. These parameters include: start time offset (start_sec), processing time (duration_sec), frame extraction interval (every_sec), and maximum number of frames to extract (max_frames). The module also calculates a quality score for each extracted frame (including blurriness, overexposure ratio, number of bright connected components, etc.), performs gating based on the quality score, marks low-quality frames but retains them, and reduces their weight in subsequent evidence aggregation calculations. The quality scores and gating marks of all frames are written to a quality gating log file for auditing and backtracking. After frame extraction, a candidate frame set is output.

[0164] 3. Detection and tracking module, used to detect street light targets in each frame of image, perform multi-target tracking on the detection boxes, and output the object identifier of each detection box (due to occlusion, low confidence, etc., some detection boxes may not be able to obtain valid identifiers).

[0165] This module is used to perform streetlight target detection on each frame in the candidate frame set by calling the trained YOLO object detection model. Detection parameters include: model weight file path (weights), computing device (device), input image size (imgsz), detection confidence threshold (conf), non-maximum suppression IoU threshold (iou), and target class to be detected (class_ids). This module can selectively enable multi-target tracking mode, using either BoT-SORT or ByteTrack trackers, and configuring relevant tracking parameters (including track_high_thresh, track_low_thresh, new_track_thresh, track_buffer, etc.) to obtain a cross-frame tracking identifier (track_id) for each detection box. The output is a list of detection boxes for each frame, each containing bounding box coordinates, confidence score, and, if tracking is enabled, a tracking ID.

[0166] 4. Cross-frame association clustering module, which is used to aggregate detection boxes based on existing object identifiers, otherwise to cluster them based on the similarity between detection boxes, and associate the detection boxes of the same street light to form a light cluster.

[0167] This module is used to aggregate detection frames belonging to the same physical street light into light clusters based on the detection frame sequence output by the detection and tracking module, and assign a unique lamp identifier (lamp_id) to each light cluster. Specifically, it uses one of the following two methods: When multi-target tracking outputs object identifiers, the detection boxes are aggregated into light clusters according to the object identifiers; When there is no object identifier, clustering is performed based on the condition that the intersection-union ratio of the detection box and the light cluster representative box is not less than the preset threshold cluster_iou, and the minimum number of votes min_cluster_votes is met.

[0168] Output the lamp cluster registry, which records information such as the representative frame corresponding to each lamp identifier, the frame number it contains, and the timestamp list.

[0169] 5. Cropping and enhancement module, used to perform multi-scale cropping and image enhancement on multiple frames of images corresponding to each light cluster to form a cropped image.

[0170] This module performs multi-scale cropping and image enhancement on each light cluster based on each recorded image frame and its corresponding detection box to generate a cropped image. The multi-scale cropping includes: basic cropping (direct cropping based on the detection box), edge-expanding cropping (expanding the detection box by a preset expansion ratio `crop_padding`), and contextual cropping (using a larger expansion ratio to include the light arm, pole, and surrounding road surface in the cropped image). The image enhancement includes at least one of CLAHE (Contrast Limiting Adaptive Histogram Equalization), Gamma correction, lightweight denoising, and sharpening. The cropped images are compressed to ensure that the size of a single image does not exceed the limitations of the large visual model interface. Information such as the cropping scale and enhancement parameter version number used for each image is recorded. The cropped image sequence for each light cluster is output, stored in a specified directory, and a cropping index file is generated, recording information such as the source frame, cropping scale, compression ratio, and quality score for each image.

[0171] 6. Sampling module, used to uniformly sample the cropped image over time, and remove or downweight low-quality frames according to quality indicators to obtain evidence image sequence.

[0172] This module is used to uniformly sample cropped images within a cluster of lights over time, ensuring that the number of samples does not exceed the preset maximum number of images per light (max_images_per_lamp), and to remove low-quality frames or reduce their weight in the calculation based on image quality indicators, thereby obtaining an evidence image sequence.

[0173] 7. Visual large model determination module, used to call the visual large model to perform structured determination and obtain structured return.

[0174] This module is used to call a large visual model for structured decision-making. It supports a single-stage mode (directly outputting the final state) and a two-stage mode (first determine ON, then OFF / UNCERTAIN if not ON). When calling the API, the response format parameter (response_format) can be set, using either JSON or JSON Schema mode to ensure the output is parsable and the fields are complete. This module outputs a structured JSON result containing street light status, confidence level, and evidence fields.

[0175] 8. The post-processing module is used to verify, calculate confidence, and correct business rules for the structured results returned by the large visual model to obtain the final judgment result.

[0176] This module is used for post-processing of the structured JSON results returned by the large visual model, including evidence field normalization, confidence score fusion recalibration, and business rule correction. Specifically, it includes: Validate field integrity; fill in missing fields with the default value UNKNOWN. The base confidence level c0 is provided by the model output; the ON support segment s_on is provided by lamp_head_glowing. 、 lamp_head_dark_visible 、 The target_visibility field is used for weighted calculation; OFF supports the division of s_off by target_visibility=YES, lamp_head_glowing=NO, lamp_head_dark_visible=NO, and low background interference for weighted calculation; The final confidence level is calculated using the formula confidence_final = clip(α*c0 + β*max(s_on, s_off), 0,1) (α and β are preset weights, such as 0.5 each); for the UNCERTAIN state, a confidence level cap is set (e.g., not exceeding 0.6). Execute business rule corrections: Rule 1 (force ON), Rule 2 (UNCERTAIN downgrade to OFF), Rule 3 (UNCERTAIN maintains and generates re-inspection recommendations); Output the final judgment result for each lamp cluster, which can be written to a structured file (such as lamp_review.csv) and an audit file for each lamp cluster (such as lamp_ <id>_parsed.json).

[0177] As an optional implementation, this system may also include an optional alarm generation and automatic notification module, and a data entry and visualization verification module:

[0178] 1. The alarm generation and automatic notification module is used to generate tiered alarms based on the final judgment results output by the post-processing module and automatically push them to the operation and maintenance system. Specifically, it includes: Alarm classification: P0 alarm (status is OFF and confidence level is not lower than 0.75, or both inspection windows are judged as OFF); P1 alarm (status is UNCERTAIN and there is a potential anomaly, such as inconsistent timing, or re-inspection suggestions generated by the post-processing module); P2 alarm (inconsistent model judgment results or seriously insufficient evidence, only recorded). The notification payload assembly includes street light identifier (lamp_id), geographic location (GPS coordinates), inspection time window, final status, confidence level, evidence field summary, evidence screenshot URL, original model response hash, model version, and rule correction record; Push method: Push to instant messaging systems such as WeChat Work, DingTalk or Lark via Webhook, and call the API of the operation and maintenance work order system to create or update work orders and associate media evidence packages; Visualized review output: Generate a review image or short video by combining the original panoramic frame (with the light head position marked) with a multi-scale cropped mosaic, as an attachment to the work order.

[0179] 2. The data entry and visualization verification module is used to store all data generated during the entire inspection process into the database.

[0180] The data imported into the database includes, but is not limited to, original frame quality gating records, detection and tracking results, light cluster registry entries, cropping indexes, visual large model requests and responses, evidence field normalization results, business rule correction records, final judgment results, and alarm events. This data is stored in a database (such as PostgreSQL or MongoDB), and a visual review page is generated for each light. The visual review page includes: a panoramic view (a screenshot of the original video frame with the light head positions marked), a cropping sequence mosaic (multiple cropped images arranged in chronological order), a judgment result card (final status, confidence level, evidence fields, correction reasons, and re-inspection suggestions), and alarm information (alarm level, work order ID, and push time). Maintenance personnel can filter alarm levels with a single click through the web interface and manually review the UNCERTAIN results. All review operations are recorded in the database, forming a complete audit chain.

[0181] After the drone acquisition module collects video, it sequentially passes through a frame sampling module, a detection and tracking module, a cross-frame association and clustering module, and a cropping and enhancement module to generate cropped images for each light cluster. The sampling module performs uniform sampling on the cropped images to obtain evidence image sequences. The sample assembly and prompt word generation module assembles prompt words. The visual large model judgment module (in conjunction with the network proxy, timeout, and retry strategy module) calls VLM to obtain structured output. The post-processing module performs normalization and correction to obtain the final judgment result. If optional modules are deployed, alarms are generated and pushed based on the judgment results, and the entire process data is simultaneously stored in the database and a review page is generated. The modules work together to achieve a complete closed loop from video acquisition to automatic notification, and the deployment of optional modules can be flexibly selected according to actual operation and maintenance needs.

[0182] The specific implementation parameters of each module (such as frame extraction interval, detection confidence threshold, clustering IoU threshold, pruning expansion ratio, number of samples per light, number of supported samples, α / β weight, etc.) can be configured according to the actual scenario. Please refer to the aforementioned embodiment of an AI-based LED street light drone inspection method, which will not be elaborated here.

[0183] Example 3

[0184] This embodiment proposes an electronic device, which is an edge computing device and a cloud server; the electronic device includes a memory and a processor, the memory being used to store computer programs for executing the aforementioned AI-based unmanned aerial vehicle (UAV) inspection method for LED streetlights. Specifically:

[0185] 1. Edge computing devices The edge computing device is deployed at the drone inspection site and includes:

[0186] A memory used to store computer programs. The memory may be random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0187] A processor is used to execute a computer program stored in the memory. The processor may be a general-purpose processor (including a central processing unit (CPU), a network processor (NP), etc.), or a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0188] When the processor executes the computer program stored in the memory, it implements steps S2 to S6 in the aforementioned embodiment of the AI-based LED street light drone inspection method. For the specific implementation of each step, please refer to the detailed description in the aforementioned embodiment of the AI-based LED street light drone inspection method, which will not be repeated here.

[0189] 2. Cloud server The cloud server is deployed in a remote data center and includes:

[0190] Memory is used to store computer programs.

[0191] A processor for executing computer programs stored in the memory.

[0192] When the processor executes the computer program stored in the memory, it implements steps S7 to S8 in the aforementioned embodiment of the AI-based LED street light drone inspection method. For the specific implementation of each step, please refer to the detailed description in the aforementioned embodiment of the AI-based LED street light drone inspection method, which will not be repeated here.

[0193] As an optional implementation, the cloud server also includes optional steps, namely steps S9 and S10, in the aforementioned embodiment of an AI-based LED street light drone inspection method.

[0194] For the specific implementation methods of the above steps, please refer to the detailed description in the aforementioned embodiment of an AI-based LED street light drone inspection method, which will not be repeated here.

[0195] The edge computing device is connected to the cloud server via a network. After completing steps S2 to S6, the edge computing device uploads the cropped evidence image sequence and metadata to the cloud server. Upon receiving the data, the cloud server executes steps S7 to S9 and returns or pushes the judgment result and alarm information to the operation and maintenance system.

[0196] The electronic devices (edge ​​computing devices and cloud servers) described in this embodiment, by executing the aforementioned computer program, can achieve automated, interpretable, and traceable intelligent inspection of nighttime streetlights, and optionally complete automatic alarm notifications and visual verification of results. Those skilled in the art will understand that the above steps can also be flexibly allocated to a single electronic device or distributed electronic devices for execution, depending on computing resources and network conditions.

[0197] Example 4

[0198] This embodiment proposes a computer-readable storage medium for storing a computer program. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the aforementioned AI-based unmanned aerial vehicle (UAV) inspection method for LED streetlights.

[0199] Depending on the deployment method, the computer-readable storage medium can be a storage medium deployed on an edge computing device or a storage medium deployed on a cloud server.

[0200] 1. Computer-readable storage media on edge computing devices

[0201] When the computer-readable storage medium is deployed on an edge computing device (such as a GPU box on the field side), the computer program stored therein is executed by the processor to implement steps S2 to S6 in the aforementioned embodiment of an AI-based LED street light drone inspection method, namely frame extraction, target detection, cross-frame association, cropping enhancement, and sampling steps.

[0202] 2. Computer-readable storage media on cloud servers

[0203] When the computer-readable storage medium is deployed on a cloud server, the computer program stored therein is executed by a processor to implement steps S7 to S8 in the aforementioned embodiment of an AI-based LED street light drone inspection method, supporting sample loading and request assembly, large visual model invocation, and post-processing steps.

[0204] As an optional implementation, it also includes steps S9 and S10 in the aforementioned embodiment of an AI-based LED street light drone inspection method.

[0205] After the computer program on the edge computing device finishes execution, it uploads the cropped evidence image sequence and metadata to the cloud server. The computer program on the cloud server receives the data, performs subsequent processing, and returns or pushes the judgment result and alarm information to the operation and maintenance system.

[0206] For the specific implementation methods of the above steps, please refer to the detailed description in the aforementioned embodiment of an AI-based LED street light drone inspection method, which will not be repeated here.

[0207] The computer-readable storage medium can be any tangible medium capable of storing computer programs, such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, solid-state drive (SSD), hard disk drive (HDD), optical disc (CD-ROM, DVD), etc.

[0208] The computer-readable storage medium described in this embodiment, when the computer program therein is executed by a processor, can realize automated, interpretable, and traceable intelligent inspection of nighttime road streetlights, and optionally complete automatic alarm notification and result visualization verification.

[0209] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.< / id> < / id>

Claims

1. A method for unmanned aerial vehicle (UAV) inspection of LED streetlights based on artificial intelligence, characterized in that, include: Acquire road lighting video captured by drone; The road lighting video is sampled at preset time intervals to obtain a candidate frame set; For each frame image in the candidate frame set, a target detection model is used to detect street light targets to obtain detection boxes. Multi-target tracking is performed on the detection boxes to obtain the object identifiers of each detection box. The detection boxes are aggregated based on the object identifier, or clustered based on the similarity between the detection boxes when the object identifier is missing, and the detection boxes of the same physical street light are associated across frames to form a light cluster; For each light cluster, acquire multiple frames of images corresponding to the detection box associated with the light cluster, and perform multi-scale cropping to form a cropped image. The cropped image retains at least the light core region of the light head and the context region including the light arm, pole, or surrounding road surface. The cropped images within the light cluster are sampled uniformly over time, ensuring that the number of samples does not exceed the preset maximum number of images per light. Low-quality frames are removed or their weight in the calculation is reduced based on image quality indicators to obtain the evidence image sequence. A request to invoke a visual big model is generated based on the evidence image sequence and input into the visual big model. The visual big model performs a preset mode judgment based on the request and outputs a structured return. The structured return includes at least the street light status and multiple predefined evidence fields. The structured return is post-processed, and the post-processing includes at least executing business rule corrections to obtain the final judgment result.

2. The method according to claim 1, characterized in that, The step of performing multi-target tracking on the detection boxes to obtain object identifiers for each detection box, and then performing similarity clustering of the detection boxes based on the object identifiers or the detection boxes themselves, includes: When multi-target tracking outputs object identifiers, the detection boxes are aggregated into light clusters according to the object identifiers; When the detection box does not have an object identifier, clustering is performed based on the condition that the intersection-union ratio of the detection box and the light cluster representative box is not less than a preset threshold and the minimum number of votes is met.

3. The method according to claim 1, characterized in that, The multi-scale cropping includes: Basic clipping, edge-expanding clipping, and context-based clipping, with edge-expanding clipping and context-based clipping using different expansion ratios.

4. The method according to claim 1, characterized in that, The predefined evidence fields include at least several of the following five: Visibility of the light source core, visibility of the dark area of ​​the light source, target visibility, background interference level, and timing consistency.

5. The method according to claim 4, characterized in that, The determination of the preset mode includes a single-stage mode or a two-stage mode; the two-stage mode includes: The first stage determines whether the street light is ON. If the output is ON, the status result is output directly. If the output is NOT_ON, the second stage is triggered to further distinguish between OFF and UNCERTAIN status.

6. The method according to claim 5, characterized in that, The business rule correction includes: If the visual model determines that the street light is OFF, but the visibility of the light source in the evidence field is YES, then it will be forcibly corrected to ON. If the visual model determines the street light status as UNCERTAIN and simultaneously satisfies the following conditions: dark area visibility at the light head is YES, light head visibility is YES, background interference is NO, and temporal consistency is YES, then the status is downgraded to OFF; otherwise, UNCERTAIN is maintained and a re-inspection suggestion is generated.

7. The method according to claim 1, characterized in that, After obtaining the final determination result, at least one of the following is also included: Based on the final determination result, a tiered alarm is generated and automatically notified to the operation and maintenance system; A visual review page is generated based on the final judgment result, and the final judgment result and the index of the evidence image sequence are stored in the database.

8. An AI-based unmanned aerial vehicle (UAV) inspection system for LED streetlights, characterized in that: include: The drone data acquisition module is used to acquire video of road lighting. The frame sampling module is used to extract frames from the video at preset time intervals and calculate quality scores for gating judgment. The detection and tracking module is used to detect street light targets in each frame of the image, perform multi-target tracking on the detection boxes, and output the object identifiers of each detection box; The cross-frame association clustering module is used to aggregate detection boxes based on existing object identifiers, or to cluster them based on the similarity between detection boxes, and to associate detection boxes of the same physical street light into light clusters across frames; The cropping and enhancement module is used to perform multi-scale cropping and image enhancement on multiple frames of images corresponding to each light cluster to form a cropped image. The sampling module is used to uniformly sample the cropped image over time and remove or downweight low-quality frames according to quality indicators to obtain the evidence image sequence. The visual large model determination module is used to call the visual large model to perform structured determination and obtain structured return. The post-processing module is used to verify, calculate confidence, and correct business rules for the structured results returned by the large visual model, so as to obtain the final judgment result.

9. An electronic device, characterized in that, The electronic device is an edge computing device and a cloud server; the electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor being used to execute the computer program to implement the corresponding steps in the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the corresponding steps in the method as described in any one of claims 1 to 7.

Images