Region-of-interest point cloud extraction method and device based on roadside laser radar, medium and product

Abstract

The embodiment of the invention relates to the field of intelligent transportation, and discloses an area-of-interest point cloud extraction method and device based on a roadside laser radar, a medium and a product. The method comprises the following steps: acquiring three-dimensional point cloud data acquired by a roadside laser radar; traversing each target point in the three-dimensional point cloud data, and calculating a mapping pixel coordinate of the target point in a pre-constructed region-of-interest configuration map according to a preset resolution parameter and a sensing range parameter; wherein the region-of-interest configuration graph is a two-dimensional aerial view, and different pixel attribute values represent a region of interest and a non-region of interest; querying a pixel attribute value corresponding to the mapping pixel coordinate in the region-of-interest configuration graph; if the pixel attribute value corresponds to the non-interested area, removing a target point from the three-dimensional point cloud data; and if the pixel attribute value corresponds to the region of interest, reserving the target point as the point cloud of the region of interest.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation, and in particular to a method, device, medium, and product for extracting region-of-interest point clouds based on roadside lidar. Background Technology

[0002] With the rapid development of Intelligent Transportation Systems (ITS) and Vehicle-to-Infrastructure (V2X) technologies, roadside perception systems are playing an increasingly important role in traffic management and autonomous driving assistance. Within the Roadside Perception Unit (RSU), LiDAR, due to its high precision and strong anti-interference capabilities, has become the core sensor for acquiring three-dimensional information about traffic scenes. LiDAR can scan dense point cloud data covering the entire field of view in real time, containing environmental information such as roads, vehicles, pedestrians, and surrounding buildings and trees.

[0003] However, in practical roadside perception applications, due to the wide scanning range and massive data volume of LiDAR, performing subsequent target detection, tracking, and classification on all point cloud data within the field of view would consume enormous computing resources and transmission bandwidth, leading to increased system latency and making it difficult to meet real-time requirements. In fact, roadside perception systems typically only need to focus on the road surface and the traffic participants above it, the so-called "region of interest" (ROI), while a large amount of off-road background (such as buildings, flower beds, and open spaces) is invalid information. Current technologies typically employ manual methods to manually calibrate or draw ROIs to remove these invalid backgrounds, such as manually selecting the road area on a point cloud map. This method is not only time-consuming and labor-intensive, heavily reliant on human experience, but the generated areas are usually static and regular geometric shapes, making it difficult to accurately reflect the complex actual road layout (such as curves and irregular intersections). Summary of the Invention

[0004] One objective of this application is to provide a method, device, medium, and product for extracting region of interest (ROI) point clouds based on roadside lidar, at least to solve the technical problems of large data processing volume and low efficiency of ROI construction in existing roadside sensing systems.

[0005] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0006] In a first aspect, some embodiments of this application provide a method for extracting point clouds of regions of interest based on roadside lidar, the method comprising:

[0007] Acquire 3D point cloud data collected by roadside lidar;

[0008] For each target point in the 3D point cloud data, the mapped pixel coordinates of the target point in a pre-constructed region of interest (ROI) configuration map are calculated based on preset resolution parameters and perception range parameters. The ROI configuration map is a 2D bird's-eye view, and different pixel attribute values ​​represent ROI and non-ROI regions. The corresponding pixel attribute values ​​of the mapped pixel coordinates in the ROI configuration map are then queried.

[0009] If the pixel attribute value corresponds to a region of non-interest, the target point is removed from the 3D point cloud data; if the pixel attribute value corresponds to a region of interest, the target point is retained as a region of interest point cloud.

[0010] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0011] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0012] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0013] Compared with related technologies, the solution provided in this application achieves rapid filtering of roadside LiDAR point cloud data by constructing a region of interest (ROI) configuration map offline and combining it with online analysis. By mapping the 3D point cloud to pre-configured 2D pixel coordinates and querying attributes, a large number of non-road background point clouds can be quickly eliminated with minimal computation, significantly reducing the amount of data that subsequent algorithms need to process. This greatly reduces the computational load and algorithm time of the system, improving the real-time performance of the roadside perception system. Furthermore, by utilizing historical data collected by roadside radar over a long period, the actual road traffic areas can be identified by extracting the trajectories of dynamic traffic participants and generating heatmaps. This method not only completely eliminates the tedious manual calibration process, greatly improving deployment efficiency, but also generates ROIs that accurately match the actual driving trajectories of vehicles and intersection shapes, making it more objective and accurate than manual drawing. Simultaneously, by statistically analyzing the height distribution characteristics of historical data at each pixel location, a configuration map containing effective height intervals is constructed. This improvement enables the present invention to effectively handle complex three-dimensional traffic scenarios such as overpasses and viaducts. It can accurately retain point clouds of specific road surfaces while removing interference points above (such as suspended objects) or below (such as the ground under a bridge) at that location, significantly improving the accuracy of point cloud extraction and the robustness of the system in complex scenarios. Attached Figure Description

[0014] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0015] Figure 1 An exemplary flowchart of a region-of-interest point cloud extraction method based on roadside lidar provided for some embodiments of this application;

[0016] Figure 2 A schematic diagram of point cloud collected in a method for extracting region of interest based on roadside lidar provided in some embodiments of this application;

[0017] Figure 3 A schematic diagram of the region of interest (ROI) point cloud in a method for extracting ROI point clouds based on roadside lidar provided in some embodiments of this application;

[0018] Figure 4 A schematic diagram illustrating the annotation of non-interest regions in a point cloud extraction method for regions of interest based on roadside lidar provided in some embodiments of this application;

[0019] Figure 5 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

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

[0021] Figure 1 An exemplary flowchart of a region-of-interest point cloud extraction method based on roadside lidar provided in some embodiments of this application, the method comprising:

[0022] S101. Acquire 3D point cloud data collected by roadside lidar.

[0023] Specifically, the roadside perception system utilizes lidar equipment fixedly installed at traffic intersections or road edges to perform real-time scanning of the current traffic scene. Lidar emits and receives laser beams to measure the spatial position information of objects within its field of view, thereby generating current frame 3D point cloud data containing a large number of discrete points (e.g., ...). Figure 2 Each point contains three-dimensional spatial coordinates (x, y, z), reflecting the geometric features of roads, vehicles, pedestrians, and the surrounding environment.

[0024] S102. Traverse each target point in the three-dimensional point cloud data, and calculate the mapped pixel coordinates of the target point in the pre-constructed region of interest configuration map according to the preset resolution parameters and perception range parameters; wherein, the region of interest configuration map is a two-dimensional bird's-eye view, and different pixel attribute values ​​represent regions of interest and non-regions of interest.

[0025] Specifically, the system reads each point (i.e., the target point) in the current frame point cloud one by one. Using pre-defined perception range parameters (such as the starting x and y coordinates of the field of view) and resolution parameters (i.e., the actual physical distance represented by each pixel), it maps the three-dimensional horizontal coordinates of the target point to the coordinate system of a two-dimensional region of interest (ROI) configuration map using a coordinate transformation formula. This calculates the specific row and column number of the point in the ROI configuration map matrix, i.e., the mapped pixel coordinates. The ROI configuration map is a two-dimensional bird's-eye view, where different pixel attribute values ​​represent ROIs and non-ROIs. In this step, the configuration map is typically constructed during the initial system deployment or offline phase. This configuration map is a rasterized image formed by projecting three-dimensional space onto a two-dimensional plane (BEV), and its resolution and coverage must match the actual detection requirements. In the configuration map, pixels representing actual road traffic areas are assigned specific attribute values ​​(e.g., non-white or specific color coding) and marked as ROIs according to predefined rules; while pixels representing irrelevant backgrounds such as roadside buildings, trees, and open spaces are assigned another attribute value (e.g., white) and marked as non-ROIs.

[0026] S103. Query the pixel attribute value corresponding to the mapped pixel coordinates in the region of interest configuration map.

[0027] Specifically, after calculating the exact location of the target point in the configuration map, the system uses the mapped pixel coordinates as an index to directly access the region of interest configuration map data stored in memory. The system reads the pixel value (such as color value or grayscale value) at that coordinate location, which is the region attribute corresponding to that spatial location in the predefined scene model.

[0028] S104. If the pixel attribute value corresponds to a region of non-interest, the target point is removed from the 3D point cloud data; if the pixel attribute value corresponds to a region of interest, the target point is retained as a region of interest point cloud.

[0029] Specifically, the system performs logical judgments based on the attribute values ​​retrieved in step S103: if the attribute value indicates that the location belongs to a non-interest region (e.g., the retrieved color is white), then the point is determined to be invalid background interference and deleted from the point cloud dataset; conversely, if the attribute value indicates that the location belongs to an interest region, then the point is determined to be valid traffic participant or road surface information and retained. After the traversal is complete, the remaining point set is the clean interest region point cloud (e.g., ...). Figure 3 ).

[0030] In this embodiment, by decomposing the complex spatial region determination process into two stages—offline configuration map construction and online coordinate mapping query—the operational efficiency of the roadside perception system is greatly optimized. This eliminates the need for complex geometric boundary calculations or deep learning inference in every frame of data processing; instead, it allows for the rapid removal of massive amounts of non-road background noise using only low-cost two-dimensional pixel indexing. This method not only significantly reduces the algorithm's time consumption and computational resource usage but also effectively reduces off-road false detections through rigorous region masking, ensuring that subsequent object detection algorithms can focus on processing high-value data in core road areas.

[0031] In one embodiment, the method for constructing the region of interest configuration map specifically includes:

[0032] S201. Collect multiple frames of raw point cloud data from the roadside lidar within a preset historical time period.

[0033] Specifically, the first step involves data acquisition, which involves collecting multiple consecutive frames of raw point cloud data from the roadside lidar within a preset historical time period. In this step, the roadside perception system does not rely solely on single-frame data for decision-making; instead, it opens a relatively long time window (the preset historical time period), such as continuously collecting data for 24 hours or covering morning and evening rush hours. During this period, the roadside lidar maintains fixed-point scanning, acquiring reflection information from all objects passing through its field of view within that time period, forming a massive sequence of consecutive, multi-frame raw point cloud data. This process ensures that the collected data samples have sufficient statistical significance and can cover various changes in traffic flow and vehicle trajectories.

[0034] S202. Background filtering is performed on the original point cloud data to extract the point cloud data of dynamic traffic participants.

[0035] Specifically, the collected raw point cloud data undergoes background filtering to extract point cloud data of dynamic traffic participants. Because the installation location of the roadside lidar is fixed, stationary objects such as road surfaces, roadside buildings, trees, and lampposts in the field of view have long-term unchanging spatial coordinate characteristics in the point cloud, constituting a static background. The system employs background filtering algorithms (such as mean filtering based on multi-frame statistics or Gaussian mixture models) to identify and remove these long-standing static background points. After processing, the remaining point cloud data mainly consists of moving targets such as vehicles, pedestrians, and non-motorized vehicles, which constitute the extracted point cloud data of dynamic traffic participants.

[0036] S203. Project the point cloud data of the dynamic traffic participants onto a two-dimensional bird's-eye view coordinate system, count the cumulative number or frequency of occurrence of point clouds at each pixel position, and generate a trajectory heat map.

[0037] Specifically, the point cloud data of the dynamic traffic participants is projected onto a two-dimensional bird's-eye view coordinate system, and the cumulative number or frequency of point clouds at each pixel location is counted to generate a trajectory heatmap. A two-dimensional grid with the same resolution as the final configuration map is established, and the three-dimensional coordinates of all extracted historical dynamic point clouds are projected onto this two-dimensional bird's-eye view plane. For each pixel location in the grid, the system sets a counter to count the total number or frequency of dynamic point clouds falling at that location during the historical period. As the data accumulates, the pixel count value will be very high in road areas where vehicles actually pass through; while in non-traffic areas such as green belts or inside buildings, the count value is extremely low because there are few dynamic targets passing through. This statistical distribution ultimately forms a trajectory heatmap that intuitively reflects the spatial distribution of traffic flow.

[0038] S204. The trajectory heatmap is binarized according to a preset density threshold. Regions with density values ​​higher than the density threshold are marked as regions of interest, and the remaining regions are marked as regions of non-interest, thereby generating a region of interest configuration map.

[0039] Specifically, the trajectory heatmap is binarized according to a preset density threshold. Regions above the threshold are marked as regions of interest (ROIs), and the remaining regions are marked as non-ROIs, thus generating the ROI configuration map. To remove occasional interference from sporadic dynamic points caused by fallen leaves, birds, or sensor noise, the system sets a reasonable density threshold. The system iterates through each pixel of the heatmap. If the statistical value of a pixel is higher than the threshold, it indicates that the location is frequently traversed by vehicles, and it is marked as a ROI (assigned a valid attribute value); conversely, if it is lower than the threshold, it is marked as a non-ROI (assigned an invalid attribute value, such as white). After this binarization operation, the blurry heatmap is transformed into a ROI configuration map with clear edges, completing the automatic construction from historical data to the detection mask.

[0040] In this embodiment, the region of interest generated based on historical dynamic trajectory statistics can realistically and objectively reflect the driving path of vehicles in actual traffic scenarios. Compared with manually drawn regular geometric figures, this method can automatically generate regions of interest and more accurately fit the actual shape of curves, irregular intersections or guide lines, effectively avoiding missed or false detections caused by manual calibration errors, and significantly improving the environmental adaptability and robustness of the roadside perception system.

[0041] After generating the region of interest configuration map that covers the field of view of the roadside lidar, the method further includes:

[0042] Morphological closing operations are performed on the binarized image to fill discontinuous holes within the region of interest.

[0043] Specifically, in actual traffic flow data statistics, due to the randomness of vehicle trajectories or the discreteness of LiDAR sampling, the generated initial binary image often contains small black holes or breaks within the road area (e.g., gaps between lane lines that are not frequently driven over, or sampling blind spots caused by data sparsity). To ensure the integrity of the region of interest, the system uses a morphological closing operation algorithm to select structuring elements of appropriate size to scan the binary image. This operation can effectively bridge narrow breaks, fill small holes within the foreground region, and connect the originally discontinuous trajectory points into a dense and complete connected domain, thereby avoiding the erroneous removal of valid point clouds located in the middle of the road during subsequent filtering.

[0044] In one embodiment, after generating the configuration map of the region of interest covering the field of view of the roadside lidar, the method further includes:

[0045] Morphological dilation is performed on the binarized image to expand the edges of the region of interest (ROI) to form a ROI with a safety margin.

[0046] Specifically, while historical trajectory data can reflect the main traffic areas, it cannot completely cover all extreme or sudden situations (such as vehicles temporarily avoiding obstacles, large vehicles having large turning radii, or vehicles driving close to the edge). If only historical trajectory data is strictly cropped, some vehicle point clouds at the edges may be mistakenly deleted. Therefore, the system further performs a morphological dilation operation on the binary image after the above processing, uniformly expanding the boundary of the region of interest outward by a certain number of pixels (this number can be set according to the safety redundancy requirements of the roadside scene). This step is equivalent to adding a redundancy ring around the statistically determined core road area, thus forming the final region of interest configuration map containing a safety margin.

[0047] In this embodiment, the quality and robustness of the region of interest (ROI) configuration map are greatly improved by introducing morphological closing and dilation operations. Closing operations ensure the continuity within the road area, preventing the target object from being incorrectly segmented due to data sparsity; while dilation operations provide the system with a necessary fault tolerance space, effectively preventing the algorithm from cutting off edge information of vehicles due to slight deviations from the historical main trajectory, thereby significantly reducing the false detection rate of the roadside perception system in edge scenarios and ensuring the integrity and security of point cloud data extraction.

[0048] In one embodiment, the step of retaining the target point as a region of interest point cloud if the pixel attribute value corresponds to a region of interest includes:

[0049] When the pixel attribute value corresponds to the region of interest, the height value of the target point in the current frame's 3D point cloud data is obtained;

[0050] Query the effective height range corresponding to the mapped pixel coordinates in the region of interest configuration map;

[0051] Determine whether the height value is within the effective height range; if yes, retain the target point as a region of interest point cloud; if no, remove the target point from the 3D point cloud data.

[0052] Specifically, for points that have been preliminarily identified as regions of interest (ROIs) on the 2D bird's-eye view, the system performs a more refined secondary filtering based on the height dimension. When the system finds that the pixel attribute value corresponding to the mapped pixel coordinates of a target point belongs to the ROI, it first extracts the height value (i.e., the Z-axis coordinate) from the target point's original 3D coordinate data. At this point, the ROI configuration map is not just a simple 2D mask image; each pixel position is also associated with a pre-defined effective height range (e.g., the range between the lowest and highest elevation limits of the road surface at that location). Based on the previously calculated mapped pixel coordinates, the system queries the corresponding effective height range in the height constraint matrix of the configuration map. Next, the system compares the extracted target point height value with the queried effective height range: if the height value falls within the effective height range (i.e., greater than or equal to the minimum effective height and less than or equal to the maximum effective height), the point is determined to be a genuine effective road surface point or traffic participant and is retained; otherwise, if the height value exceeds the effective height range (e.g., a suspended sign located above the road surface, or a non-target road section on the upper or lower level of an overpass), the point is determined to be an interference point in three-dimensional space and is removed from the point cloud data.

[0053] In this embodiment, by introducing height dimension constraints on top of the two-dimensional plane, different levels of roads often overlap in the two-dimensional bird's-eye view in scenarios such as overpasses, elevated roads, or multi-level roads. Pixel position alone cannot distinguish whether a target vehicle is on or under the bridge. By limiting the effective height range, accurate extraction of regions of interest at specific levels is achieved. This effectively filters out interference objects that, although projected within the road area, are actually located in non-traffic areas in vertical space (such as gantries, traffic lights, tree canopies, or vehicles not at the target level), thus significantly improving the detection accuracy and spatial resolution of the roadside perception system in complex urban road environments.

[0054] In one embodiment, the effective height range is constructed in the following ways:

[0055] When generating the region of interest configuration map, the height distribution characteristics of the historical dynamic traffic participant point cloud falling within each pixel coordinate are statistically analyzed.

[0056] Based on the height distribution characteristics, kernel density estimation is performed to generate the statistical extreme value of the height probability density function;

[0057] Based on the main peak distribution range of the height probability density function, the minimum and maximum effective heights corresponding to the pixel coordinates are determined to construct the effective height interval covering all pixels. Specifically, when generating the region of interest configuration map, the system not only counts the number of point clouds at each pixel location but also simultaneously counts the height distribution characteristics of historical dynamic traffic participant point clouds falling within each pixel coordinate. The system establishes a spatial index with the same resolution as the two-dimensional bird's-eye view and traverses all dynamic point cloud data within a preset historical time period. For each pixel, the system collects the Z-axis height values ​​of all dynamic points projected onto that coordinate, forming a height value set. This set reflects the vertical spatial distribution of all historically passing vehicles or pedestrians at that specific geographical location (for example, the vehicle heights on the upper surface of an overpass are mainly concentrated between 6 and 8 meters, while those on the lower surface are concentrated between 0 and 2 meters).

[0058] Next, based on the statistical extremes of the height distribution characteristics or the range of the main peak distribution of the height probability density function, the minimum and maximum effective heights corresponding to the pixel coordinates are determined, thus forming a height constraint matrix. To eliminate accidental sensor noise or abnormal data (such as birds or very few excessively high / low points), the system does not directly use the absolute maximum and minimum values ​​in the set, but instead uses statistical methods (such as taking the 99th percentile as the upper limit and the 1st percentile as the lower limit, or a range based on the mean plus or minus the standard deviation) to determine the statistical extremes. The system writes the calculated maximum effective height into a matrix structure, where each element of the matrix corresponds to a pixel in the configuration map. Finally, a height constraint matrix is ​​formed that corresponds one-to-one with the pixels of the two-dimensional bird's-eye view, providing accurate data support for subsequent online height filtering.

[0059] In this embodiment, by utilizing real trajectory data of historical vehicles, the system can automatically learn and draw the three-dimensional undulations of the road surface. This means that without manually building complex three-dimensional road models, the system can automatically adapt to complex terrains such as slopes, uneven road surfaces, and multi-level overpasses. The generated effective height range closely matches the actual driving levels, thereby achieving high-precision extraction of regions of interest in three-dimensional space while ensuring extremely low deployment costs.

[0060] In one embodiment, the step of calculating the mapped pixel coordinates of the target point in the region of interest configuration map based on preset resolution parameters and perception range parameters specifically adopts the following formula:

[0061]

[0062] Where (x,y) are the horizontal coordinates of the target point, , ) represents the mapped pixel coordinates. For resolution parameters, and The starting coordinates are those corresponding to the sensing range parameters. Configure the height of the map for the region of interest. This is the floor function.

[0063] Specifically, the process of calculating the mapped pixel coordinates of the target point in the region of interest (ROI) configuration map is achieved through a specific linear transformation formula. Since the target point coordinates (x, y) acquired by the lidar are typically continuous floating-point values, while the ROI configuration map is a two-dimensional matrix composed of discrete pixels, a mapping relationship between the two needs to be established. The system specifically uses the above formula for calculation. (x, y) represents the horizontal physical coordinates of the target point in the lidar coordinate system; ( , The ) represents the pixel column and row coordinates mapped to the region of interest configuration map. The preset pixel resolution parameter defines the proportion of distance that one pixel in the configuration diagram represents in the actual physical environment (e.g., how many pixels per meter). and These are the starting coordinates of the preset sensing range in the X and Y axes, respectively, used to determine the reference origin for mapping; Configure the pixel height of the map for the region of interest; This is a floor function used to convert the calculation result into an integer index. The formula inverts the Y-axis coordinate and adds height to accommodate the directional differences between the computer image coordinate system (the origin is usually at the top left corner, and the Y-axis points downwards) and the LiDAR physical coordinate system (the origin is usually at the center, and the Y-axis direction may be different).

[0064] In this embodiment, the linear transformation formula used has low time complexity, so even when faced with hundreds of thousands or even millions of point cloud data per second, the coordinate index calculation of all points can be completed in a very short time, thereby ensuring the high real-time performance and low latency of the roadside perception system when processing large-scale data.

[0065] Furthermore, in one embodiment, the height parameter of the region of interest configuration map involved in the above coordinate mapping formula is not set arbitrarily, but is accurately calculated based on the actual sensing range of the roadside lidar and the preset resolution, so as to ensure that the generated bird's-eye view can completely cover the expected physical area.

[0066] Specifically, the height parameter is determined using the following formula:

[0067] ;

[0068] In the above formula, and These represent the maximum and minimum values ​​of the sensing range of the roadside lidar in the Y-axis direction, respectively, which together define the physical boundary of the region of interest in the Y-axis direction. This represents the total physical coverage length along the Y-axis. Pixel resolution (i.e., the number of pixels corresponding to 1 meter); This is the floor function. This calculation is typically completed during the initialization phase of building the deployment graph. The value not only determines the number of rows in the configuration graph matrix, but also participates as an offset parameter. In the coordinate flipping calculation.

[0069] In this embodiment, through dynamic calculation based on the physical perception range, the system can adaptively generate a configuration map with the most suitable size. The use of the round-up function ensures that even if the physical size is not divisible by the resolution, the generated image boundary can completely contain all points within the perception range, avoiding the loss of edge data; at the same time, the accurately calculated height parameter ensures the accuracy of the coordinate mapping when flipped in the Y-axis direction, so that the generated bird's-eye view maintains strict geometric consistency with the spatial relationship of the real world.

[0070] In one embodiment, in the region of interest configuration map, the pixel attribute value is a color value; wherein, pixels in the region of interest are configured with a first color value, and pixels in the non-region of interest are configured with a second color value;

[0071] The query for the pixel attribute values ​​corresponding to the mapped pixel coordinates in the region of interest configuration map includes:

[0072] Get the color value at the mapped pixel coordinates;

[0073] When the color value is the second color value, the pixel attribute value is determined to correspond to a region of non-interest; otherwise, the pixel attribute value is determined to correspond to a region of interest.

[0074] Specifically, the system can define the physical meaning and marking method of the Region of Interest (ROI) and Non-ROI regions in the configuration map. The RIO can be physically mapped to the road surface area used by vehicles and pedestrians, which is the core area that the roadside perception system needs to monitor. The NRO corresponds to areas outside the road surface, such as the exterior walls of buildings, green belts, open spaces outside sidewalks, and the sky background. When constructing the RIO configuration map, the system uses color coding to facilitate rapid computer recognition. All pixels identified as NRO are uniformly marked with a first color (e.g., pure white with an RGB value of (255, 255, 255)). Conversely, pixels belonging to the RIO can be marked with any color other than the first color (e.g., black, yellow, or a color representing a specific meaning).

[0075] Based on the aforementioned color definition, the system executes specific pixel attribute determination logic during the online processing phase. After calculating the mapped pixel coordinates of the target point in the configuration map, the system reads the pixel color value at those coordinates. The determination process is as follows: the system checks whether the read color matches the preset first color (e.g., white). If the color corresponding to the mapped pixel coordinates is indeed the first color, the system determines that the pixel attribute value at that location corresponds to a non-interest region. This means that although the 3D point cloud has been acquired by the LiDAR, its physical location is actually within a preset shielding range (e.g., hitting a wall on the side of the road), so the system will perform a culling operation; conversely, if the color is not the first color, it is determined to be an interest region and retained.

[0076] Furthermore, in one embodiment, constructing a region of interest configuration map covering the field of view of the roadside lidar further includes:

[0077] The point cloud data collected by the roadside lidar is projected onto a two-dimensional plane and the projected base map is displayed on the human-computer interaction interface.

[0078] In response to a masking command issued by the user via an input device on the projected base map, the boundaries of the area to be removed are determined;

[0079] According to the masking instruction, pixels located within the boundary of the region to be removed in the projection map are marked as pixel attribute values ​​corresponding to the non-interest region, and pixels located outside the boundary of the region to be removed are marked as pixel attribute values ​​corresponding to the interest region, thereby generating the interest region configuration map.

[0080] Specifically, the process of constructing a region of interest configuration map covering the field of view of the roadside lidar can also be completed through manual interactive annotation (e.g., Figure 4(The white area above). The system first performs the projection and display steps, projecting one or more frames of point cloud data (or accumulated background point cloud) collected by the roadside lidar onto a two-dimensional plane to generate a projection base map that clearly reflects the environmental characteristics of the current intersection or road segment. Subsequently, the system displays this projection base map on the corresponding human-machine interface (GUI), providing the user with a visual operating benchmark. At this time, by default, all areas within the entire field of view on the interface are areas to be retained.

[0081] Next, the user interaction and command reception phase begins. The system responds to masking commands issued by the user via input devices such as a mouse, touchscreen, or stylus onto the projected base map. Maintenance personnel can use tools provided in the interface, such as the "eraser," "masking brush," or "polygon selection," to paint over or select obvious non-road areas displayed on the projected base map, including buildings, roadside trees, green belts, and wasteland, based on observation and understanding of the site environment. The system calculates and determines the boundaries of the areas to be removed in real time based on these user actions.

[0082] Finally, the system executes the pixel labeling and configuration map generation steps. Based on the boundary determined by the occlusion command, the system resets the pixel attributes of the base image: all pixels in the projected base image located within the boundary of the region to be removed (i.e., the area painted by the user) are uniformly labeled with the pixel attribute values ​​corresponding to the non-interest region (e.g., filled with the first color, such as pure white); simultaneously, pixels located outside the boundary of the region to be removed (i.e., the retained area not operated by the user) are labeled with the pixel attribute values ​​corresponding to the interest region (e.g., retaining the original color or labeled as black). After processing, the system saves the labeled image, generating the final interest region configuration map.

[0083] Furthermore, in one embodiment, the region of interest (ROI) configuration map is a raster bitmap; the construction of the ROI configuration map covering the field of view of the roadside lidar specifically includes:

[0084] The point cloud data collected by the roadside lidar is converted into a two-dimensional pixel matrix using a coordinate mapping formula, an initial bitmap is generated, and the initial bitmap is displayed in a graphical user interface.

[0085] Receive image editing instructions applied to the initial bitmap; the image editing instructions include operations to smear or erase pixels;

[0086] In response to the image editing command, the pixel attribute value at the corresponding coordinate position in the initial bitmap is directly modified, and the modified bitmap is used as the region of interest configuration map.

[0087] Specifically, the system first uses the aforementioned coordinate mapping formula to map the background point cloud data or accumulated historical point cloud data collected by the roadside lidar into a two-dimensional pixel matrix, generating an initial grayscale or color bitmap. The system directly displays this initial bitmap on the accompanying graphical user interface (GUI). At this point, each pixel in the bitmap intuitively corresponds to a grid position in the physical space of the intersection. The system provides users with a set of image editing tools similar to standard drawing software (such as brushes, erasers, paint buckets, etc.). Users do not need experience operating 3D modeling software; they only need to issue image editing commands on the displayed bitmap, such as using the "eraser" tool to erase pixel areas representing roadside billboards or trees, or using the "brush" tool to paint over lane areas that require special attention.

[0088] The system responds to user-defined image editing commands on the interface without involving any complex 3D inverse projection or geometric cutting calculations. Instead, it directly modifies the pixel attribute values ​​at the corresponding coordinates in the initial bitmap within memory. For example, when the user sweeps across an area with a white eraser, the system immediately resets the attribute values ​​of all pixels within that area to values ​​representing "non-interest areas" (e.g., 255); when the user repairs lane lines with a colored pen, the system updates the corresponding pixels to values ​​representing "interest areas." After user editing and confirmation, the modified bitmap is saved as the final interest area configuration map for direct use by the online detection algorithm.

[0089] In the above embodiments, by allowing users to erase or cover obvious interference, edge scenes that are difficult for automated algorithms to judge can be effectively handled. This is an important auxiliary means for system cold start or fine-tuning, and it greatly improves the processing speed.

[0090] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0091] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0092] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 5 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0093] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0094] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0095] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0096] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0097] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0098] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0099] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0100] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0101] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0102] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0103] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0104] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for extracting point clouds of regions of interest based on roadside lidar, characterized in that, The method includes: Acquire 3D point cloud data collected by roadside lidar; Each target point in the 3D point cloud data is traversed, and the mapped pixel coordinates of the target point in a pre-constructed region of interest (ROI) configuration map are calculated according to preset resolution parameters and perception range parameters; wherein, the ROI configuration map is a two-dimensional bird's-eye view, and different pixel attribute values ​​represent the ROI and non-ROI. Query the pixel attribute value corresponding to the mapped pixel coordinates in the region of interest configuration map; If the pixel attribute value corresponds to a region of non-interest, the target point is removed from the 3D point cloud data; if the pixel attribute value corresponds to a region of interest, the target point is retained as a region of interest point cloud.

2. The method according to claim 1, characterized in that, The method for constructing the region of interest configuration map specifically includes: Collect multiple frames of raw point cloud data from the roadside lidar within a preset historical time period; Background filtering is performed on the original point cloud data to extract point cloud data of dynamic traffic participants; Project the point cloud data of the dynamic traffic participants onto a two-dimensional bird's-eye view coordinate system, count the cumulative number or frequency of occurrence of point clouds at each pixel location, and generate a trajectory heatmap. The trajectory heatmap is binarized according to a preset density threshold. Regions above the density threshold are marked as regions of interest, and the remaining regions are marked as regions of non-interest, so as to generate a region of interest configuration map.

3. The method according to claim 2, characterized in that, After generating the region of interest configuration map, the method further includes: Morphological closing operations are performed on the binarized image to fill discontinuous holes inside the region of interest; And / or, perform morphological dilation on the binarized image to expand the edges of the region of interest to form a region of interest with a safety margin.

4. The method according to claim 1, characterized in that, The step of retaining the target point as a region of interest point cloud if the pixel attribute value corresponds to a region of interest includes: When the pixel attribute value corresponds to the region of interest, the height value of the target point in the 3D point cloud data is obtained; Query the effective height range corresponding to the mapped pixel coordinates in the region of interest configuration map; Determine whether the height value is within the effective height range; If yes, the target point is retained as a region of interest point cloud; otherwise, the target point is removed from the 3D point cloud data.

5. The method according to claim 4, characterized in that, The effective height range is constructed in the following ways: When generating the region of interest configuration map, the height distribution characteristics of the historical dynamic traffic participant point cloud falling within each pixel coordinate are statistically analyzed. Based on the height distribution characteristics, kernel density estimation is performed to generate a height probability density function; Based on the main peak distribution range of the height probability density function, the minimum and maximum effective heights corresponding to the pixel coordinates are determined to construct the effective height interval covering all pixels.

6. The method according to any one of claims 1 to 5, characterized in that, The step of calculating the mapped pixel coordinates of the target point in the region of interest configuration map based on preset resolution parameters and perception range parameters uses the following formula: Where (x,y) are the horizontal coordinates of the target point, , ) represents the mapped pixel coordinates. The preset resolution parameters, and The starting coordinates are those corresponding to the sensing range parameters. Configure the height of the map for the region of interest. This is the floor function.

7. The method according to claim 1, characterized in that, In the region of interest configuration diagram, the pixel attribute value is a color value; wherein, pixels in the region of interest are configured with a first color value, and pixels in the non-region of interest are configured with a second color value; The query for the pixel attribute values ​​corresponding to the mapped pixel coordinates in the region of interest configuration map includes: Get the color value at the mapped pixel coordinates; When the color value is the second color value, the pixel attribute value is determined to correspond to a region of non-interest; otherwise, the pixel attribute value is determined to correspond to a region of interest.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images