Method for processing road boundaries and vehicle

Abstract

The present disclosure relates to a method of processing a road boundary and a vehicle. The method comprises the steps of: generating a virtual road boundary based on an effective road boundary generated from point cloud data of a first sensor; determining whether to adopt a static object as a boundary candidate based on an approximation of the virtual road boundary with the static object being perceived by the first sensor as being spaced apart from the effective road boundary; determining whether a region on the effective road boundary that is not perceived by the first sensor between a perceived road boundary and the boundary candidate is estimated to be in a present and undetected state based on the static object being adopted as the boundary candidate; generating a final road boundary based on the perceived road boundary and the static object based on the region not perceived being estimated to be in the present and undetected state.

Description

Technical Field

[0001] This disclosure relates to a method and vehicle for processing road boundaries, and more specifically, to a method and vehicle for robustly estimating objects associated with unperceived road boundaries under sensor performance limitations. Background Technology

[0002] The matters described in the Background section are only intended to enhance the understanding of the background of this disclosure and should not be construed as an admission that they correspond to prior art known to those skilled in the art.

[0003] The vehicle can support autonomous driving functions, enabling the vehicle to control driving with minimal or no driver intervention.

[0004] Vehicles can use various types of heterogeneous sensors to detect their surroundings and identify the conditions around the vehicle based on the detected conditions. The vehicle can then formulate a control plan for autonomous driving corresponding to the identified conditions, thereby controlling the vehicle's actuators.

[0005] In terms of cost and system simplification, sensors installed on vehicles can primarily include image sensors and radar sensors. Here, because radar sensors are cheaper than lidar sensors, vehicles may not include lidar sensors and only install radar sensors.

[0006] Radar sensors can provide sparse point cloud data. The sensing performance of radar sensors depends on the shape and reflectivity of objects, which may result in poor or non-existent sensor data for those objects.

[0007] Autonomous driving may involve technologies for determining the surrounding environment, such as road boundaries, to achieve accurate and safe control. However, using radar sensors to determine road boundaries can be limited or discontinuous when undetected objects or areas are present due to sensor performance limitations. Control logic that utilizes discontinuously determined road boundaries may lead to performance degradation. Summary of the Invention

[0008] Various embodiments of this disclosure are intended to provide a method and vehicle for processing road boundaries, which robustly estimates objects associated with unperceived road boundaries under sensor performance limitations.

[0009] The technical problems addressed by this disclosure are not limited to those described above, and other technical problems not mentioned will be clearly understood by those skilled in the art based on the following description.

[0010] According to this disclosure, a method performed by a vehicle may include: acquiring point cloud data associated with at least one static object in the vehicle's surrounding environment via the vehicle's sensors; detecting a road boundary based on the point cloud data; generating a virtual road boundary by extending the detected road boundary; determining whether to select the at least one static object as a boundary candidate based on the approximation of the virtual road boundary and the at least one static object, wherein the at least one static object is spaced apart from the detected road boundary; determining whether an undetected region is in a state of presence and undetection, wherein the undetected region is a region not detected by sensors and located between the detected road boundary and the boundary candidate, and wherein the presence and undetection state is an estimated state in which an object not detected by sensors exists in the surrounding environment; and outputting a signal indicating the final road boundary based on the detected road boundary, the at least one static object, and the presence and undetection state of the undetected region, and controlling the vehicle's autonomous driving based on the signal.

[0011] A vehicle may include: a sensor configured to acquire point cloud data associated with at least one static object in the vehicle's surrounding environment; a drive control circuit configured to control the vehicle's autonomous driving; and a processor circuit configured to cause the vehicle to: detect road boundaries based on the point cloud data; generate virtual road boundaries based on regression line information derived from the detected road boundaries; determine whether to select the at least one static object as a boundary candidate based on whether an approximation condition between the boundary line associated with the at least one static object and the virtual road boundary is satisfied; determine whether an undetected region is in a state of presence and non-detection, wherein the undetected region is a region not detected by the sensor and located between the detected road boundary and the boundary candidate, and wherein the presence and non-detection state is a state in which an object not detected by the sensor is determined to exist in the surrounding environment; and output a signal indicating the final road boundary based on the detected road boundary, the at least one static object, and the presence and non-detection state of the undetected region, and control the vehicle's autonomous driving via the drive control circuit and based on the signal.

[0012] The vehicle may further feature that: regression line information is derived by fitting a regression line to multiple boundary points included in the detected road boundary, and the virtual road boundary is generated by extending the regression line beyond the end portion of the detected road boundary. The vehicle may further feature that: an approximation condition is satisfied when the distance between a first point and a second point is less than or equal to a predetermined threshold distance, wherein the first point corresponds to the endpoint of an estimated boundary line associated with at least one static object, and wherein the second point corresponds to the endpoint of the virtual road boundary. The vehicle may further feature that: an unperceived region is determined to be in a present but undetected state based on the number of times the sensor fails to detect an object in the unperceived region being less than or equal to a non-existent state threshold.

[0013] According to this disclosure, a vehicle may include: a sensor configured to acquire point cloud data associated with at least one static object in the vehicle's surrounding environment; a processor; and a memory storing at least one instruction configured, when executed by the processor, to cause the vehicle to: detect a road boundary based on the point cloud data; generate a virtual road boundary by extending the detected road boundary; determine whether to select the at least one static object as a boundary candidate based on the approximation of the virtual road boundary and the at least one static object, wherein the at least one static object is spaced apart from the detected road boundary; determine whether an undetected region is in a state of presence and undetection, wherein the undetected region is a region not detected by the sensor and located between the detected road boundary and the boundary candidate, and wherein the presence and undetection state is an estimated state in which an undetected object exists in the surrounding environment; output a signal indicating the final road boundary based on the detected road boundary, the at least one static object, and the presence and undetection state of the undetected region, and control the vehicle's autonomous driving based on the signal.

[0014] A further feature of the vehicle may be that: the detected road boundary may include at least one of a perceived road boundary and a previous final road boundary, wherein the perceived road boundary is determined from point cloud data and used as the detected road boundary, and wherein the previous final road boundary is a final road boundary generated based on point cloud data acquired at a previous time. A further feature of the vehicle may be that: the virtual road boundary is generated by extending the detected road boundary using regression line information, and wherein the regression line information is derived from the detected road boundary. A further feature of the vehicle may be that: when determining whether to select at least one static object as a boundary candidate, the at least one instruction, when executed by the processor, is configured to cause the vehicle to select the at least one static object as a boundary candidate based on a threshold distance between a first point and a second point, wherein the first point corresponds to the endpoint of an estimated boundary line associated with the at least one static object, and wherein the second point corresponds to the endpoint of the virtual road boundary.

[0015] A further feature of the vehicle may be that: the virtual road boundary may include a first virtual road boundary and a second virtual road boundary, wherein the first virtual road boundary is generated based on a first detected road boundary determined from point cloud data, and wherein the second virtual road boundary is generated based on a second detected road boundary determined from image data, wherein the image data is obtained from a second sensor configured to detect the surrounding environment, and wherein, when determining whether to select at least one static object as a boundary candidate, the at least one instruction, when executed by the processor, is configured to cause the vehicle to select the at least one static object as a boundary candidate based on the at least one static object satisfying an approximation condition to at least one of the first virtual road boundary or the second virtual road boundary. A further feature of the vehicle may be that: the second virtual road boundary is generated by extending the detection range of the second sensor to a detection range corresponding to the sensor, and wherein the detection range of the sensor is greater than the detection range of the second sensor.

[0016] A further feature of the vehicle may be that, when determining whether an unperceived area is in a state of existence and non-detection, the at least one instruction, when executed by the processor, is configured to cause the vehicle to determine that the unperceived area is in a state of existence and non-detection based on the number of times the sensor has not detected an object in the unperceived area being less than or equal to a non-existent state threshold. A further feature of the vehicle may be that, when executed by the processor, the at least one instruction is configured to cause the vehicle to identify at least one static object as part of a road boundary, and to generate a final road boundary by connecting this part of the road boundary and the detected road boundary, thereby merging the at least one static object with the detected road boundary. A further feature of the vehicle may be that, when determining whether an unperceived area is in a state of existence and non-detection, the at least one instruction, when executed by the processor, is configured to: determine that the unperceived area is in a state of non-existence and non-detection based on the determination that the unperceived area is not in a state of existence and non-detection, wherein the state of non-existence and non-detection is a state in which an object is not detected by the sensor and is determined to be actually non-existent, and to generate a final road boundary based on the determination that the unperceived area is in a state of non-existence and non-detection and the detected road boundary. A further feature of the vehicle may be that the detected road boundaries are identified by detecting road structures installed in a predetermined form on the road in the environment surrounding the vehicle.

[0017] The above brief summary of the features of this disclosure is merely an exemplary embodiment of the detailed description of this disclosure and does not limit the scope of this disclosure. Attached Figure Description

[0018] The above and other objects, features and advantages of this disclosure will become more apparent to those skilled in the art from the detailed description of the accompanying drawings, wherein: Figure 1 An embodiment is shown in which a vehicle communicates with another device to send and receive data; Figure 2 Exemplary modules constituting a vehicle are shown; Figure 3 An embodiment of road boundary generation and management based on sensor data is shown; Figure 4 Exemplary modules constituting a server are shown; Figure 5 An exemplary method for handling road boundaries is shown; Figure 6 , Figure 7 and Figure 8 An example of a virtual road boundary is shown; Figure 9 This illustrates an embodiment related to state determination in unperceived areas; Figure 10This illustrates an embodiment related to state determination in unperceived areas; Figure 11 An example related to the generation of the final road boundary is shown; Figure 12 An example related to the generation of the final road boundary is shown; Figure 13 An exemplary computing system is shown. Detailed Implementation

[0019] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to readily implement the present disclosure. However, the present disclosure may be implemented in many different ways and is not limited to the embodiments described herein.

[0020] In describing exemplary embodiments of this disclosure, well-known functions or structures will not be described in detail, as they may unnecessarily obscure the understanding of this disclosure. Identical constituent elements in the drawings are denoted by the same reference numerals, and repeated descriptions of identical elements will be omitted.

[0021] In this disclosure, when an element is simply referred to as "connected to," "coupled to," or "linked to" another element, this can mean that an element is "directly connected to," "directly coupled to," or "directly linked to" another element, or is connected to, coupled to, or linked to another element in the presence of other elements interposed between them. Furthermore, when an element "comprises" or "has" another element, this means that an element may further include the other element without excluding the other component, unless otherwise specifically stated.

[0022] In this disclosure, the terms first, second, etc., are used only to distinguish one element from another and do not limit the order or importance of elements unless specifically mentioned. Thus, a first element in one embodiment may be referred to as a binary element in another embodiment, and similarly, a binary element in one embodiment may be referred to as a first element in another embodiment without departing from the scope of this disclosure.

[0023] In this disclosure, elements are distinguished from each other for the purpose of clearly describing each feature and do not necessarily mean that the elements are separate. For example, multiple elements may be integrated into a single hardware or software unit, or a single element may be distributed and formed in multiple hardware or software units. Therefore, such integrated or distributed embodiments are included within the scope of this disclosure, unless otherwise mentioned.

[0024] In this disclosure, the elements described in the various embodiments are not necessarily essential elements, and some may be optional elements. Therefore, embodiments comprising a subset of the elements described in the embodiments are also included within the scope of this disclosure. Furthermore, embodiments that include other elements besides those described in the various embodiments are also included within the scope of this disclosure.

[0025] The advantages and features of this disclosure, as well as the ways in which they are implemented, will become apparent from the embodiments described in detail below with reference to the accompanying drawings. However, the embodiments may be implemented in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be complete and comprehensive, and will fully convey the scope of this disclosure to those skilled in the art.

[0026] The terms "module" or "unit" as used in this specification refer to software and / or hardware components, and a "module" or "unit" performs a specific operation / function / role. However, a "module" or "unit" is not to be construed as limited to software or hardware. A "module" or "unit" may be configured to reside in addressable storage media or to execute one or more processors. Therefore, as an embodiment, a "module" or "unit" may include at least one of the following: such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, or variables. The functionality provided in a component, "module," or "unit" may be combined into a smaller number of components, "modules," or "units," or further divided into additional components, "modules," or "units."

[0027] In this disclosure, a "module" or "unit" can be implemented as a processor and a memory. "Processor" should be interpreted broadly to include general-purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), microcontrollers, state machines, etc. In some contexts, "processor" can refer to application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or field-programmable gate arrays (FPGAs). For example, "processor" can refer to a combination of processing devices, such as a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors with a DSP core, or any other such combination. Furthermore, "memory" should be interpreted broadly to include any electronic component capable of storing electronic information. "Memory" can refer to various types of processor-readable media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage devices, and registers. The memory can be in electronic communication with the processor when the processor can read information from the memory and / or record information in the memory. The memory integrated into the processor is in electronic communication with the processor.

[0028] One or more features described herein can provide a computer program stored in a computer-readable recording medium for execution on a computer. The medium can continuously store the computer-executable program or temporarily store the program for execution or download. Furthermore, the medium can be a variety of recording or storage devices in the form of a single hardware device or multiple combined hardware devices, and is not limited to a medium directly connected to a computer system, but can be distributed over a network. Examples of such media include: magnetic media, such as hard disks, floppy disks, or magnetic tapes; optical recording media, such as CD-ROMs or DVDs; magneto-optical media, such as floppy disks; and ROMs, RAMs, or flash memory configured to store program instructions. Other embodiments of such media include media or storage media managed by application stores that distribute applications or by various other sites or servers that provide or distribute software.

[0029] In a hardware implementation, the processing unit for performing these techniques may be implemented within one or more ASICs, DSPs, digital signal processing devices, programmable logic devices, field-programmable gate arrays, processors, controllers, microcontrollers, microprocessors, electronic devices, or computers or combinations thereof designed to perform the functions described in this disclosure.

[0030] For the purposes of this application and claims, the exemplary phrases "at least one: A; B; or C" or "at least one A, B, or C" are used, which means "at least one A, or at least one B, or at least one C, or any combination of at least one A, at least one B, and at least one C". Furthermore, exemplary phrases such as "A, B, or C", "at least one of A, B, and C", "at least one of A, B, or C", etc., may be used herein to denote each listed item or all possible combinations of listed items. For example, "at least one of A or B" may mean (1) at least one A; (2) at least one B; or (3) at least one A and at least one B.

[0031] In this disclosure, the positional expressions used in this specification, such as "upper," "lower," "left," and "right," are adopted for ease of interpretation, and the positional relationships described in the specification can be understood in reverse if the figures shown in this specification are reversed.

[0032] According to the Society of Automotive Engineers (SAE) standards, the level of automation in autonomous vehicles can be classified as follows: At Level 0 of Automated Driving, the SAE classification corresponds to "No Automation," where the automated driving system intervenes temporarily in emergency situations (e.g., automatic emergency braking) and / or only provides warnings (e.g., blind spot warning, lane departure warning, etc.), and expects the driver to operate the vehicle. At Level 1 of Automated Driving, the SAE classification corresponds to "Driver Assistance," where the system performs some driving functions (e.g., steering, acceleration, braking, lane centering, adaptive cruise control, etc.), while the driver operates the vehicle within normal operating ranges, and expects the driver to determine the system's operating status and / or timing, perform other driving functions, and respond to (e.g., resolve) emergency situations. At Level 2 of Automated Driving, the SAE classification corresponds to "Partial Automation," where the system performs steering, acceleration, and / or braking under driver supervision, and expects the driver to determine the system's operating status and / or timing, perform other driving functions, and respond to (e.g., resolve) emergency situations. At Level 3 of autonomous driving, the SAE classification standard can correspond to "conditional automation," where the system drives the vehicle under limited conditions (e.g., performing driving functions such as steering, acceleration, and / or braking), but transfers driving control to the driver when the required conditions are not met. The driver is expected to determine the system's operating state and / or timing, and take over control in emergency situations, but will not additionally operate the vehicle (e.g., steering, acceleration, and / or braking). At Level 4 of autonomous driving, the SAE classification standard can correspond to "high automation," where the system performs all driving functions, and the driver is expected to take over control of the vehicle only in emergency situations. At Level 5 of autonomous driving, the SAE classification standard can correspond to "full automation," where the system performs all driving functions without any driver assistance, including in emergency situations, and the driver is expected not to perform any driving functions other than determining the system's operating state. Although this disclosure applies the SAE classification standard for autonomous driving classification, other classification methods and / or algorithms can be used in one or more configurations described herein.

[0033] One or more features associated with autonomous driving control can be activated based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed boundary indicates a narrowing lane or roadside deviation (e.g., near a construction zone, tunnel entrance, or curved shoulder), the autonomous driving control can adjust steering or deceleration to maintain a safe offset relative to the boundary. In another embodiment, when the reconstructed boundary data predicts discontinuous or missing edges (e.g., due to heavy rain or obscured markings), the control system can temporarily reduce the level of autonomous driving and request driver intervention to ensure safe operation.

[0034] One or more auxiliary devices (e.g., engine braking, exhaust braking, hydraulic retarders, electric retarders, regenerative braking, etc.) can also be controlled based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed boundary indicates a narrowing or curving lane (e.g., near a guardrail, roadside obstacle, or tunnel wall), regenerative braking can increase braking torque to maintain a safe lateral position. In another embodiment, when the reconstructed boundary predicts an upcoming gradient or shoulder drop (e.g., detected by radar-based terrain contours), engine braking or a retarder can be pre-adjusted to stabilize vehicle deceleration and reduce the risk of lateral drift.

[0035] One or more communication devices can also be controlled based on features of road boundary reconstruction using radar-based detection and image-assisted approximation. For example, when the reconstructed boundary indicates reduced visibility or missing roadside structures (e.g., during fog, tunnel entrances, or snow accumulation), the communication devices can increase the transmission frequency of vehicle-to-everything (V2X) messages to obtain supplemental map or lane information. In another embodiment, when the confidence level of the reconstructed boundary is high, the system can temporarily reduce external data requests (e.g., from cloud servers or nearby vehicles) to conserve bandwidth and prioritize safety-critical communications.

[0036] Minimum Risk Maneuvering (MRM) operation can also be controlled based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed boundary indicates lane edge discontinuities or roadside obstacles (e.g., missing curbs, cones, or guardrails), MRM control can steer the vehicle into a safe lateral area within the detected boundary. In another embodiment, when the confidence level of the reconstructed boundary falls below a threshold (e.g., due to heavy rain or sensor obstruction), the vehicle can automatically decelerate or stop within a validated lane area to reduce collision risk before driver intervention while maintaining a stable attitude.

[0037] Offset driving maneuvers can also be controlled based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed boundary indicates a lack of clear edges on one side of the road (e.g., due to parked vehicles, snow, or poor lighting), the driving controls can deflect the vehicle's lateral position away from that side to maintain a safer distance. In another embodiment, when the reconstructed boundary reveals temporary narrowing or roadside obstacles (e.g., guardrails, cones, or curbs), the vehicle can adjust the offset target lateral distance to prevent side collisions while maintaining smooth lane-keeping control.

[0038] One or more sensors can also be controlled based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed boundary indicates lane narrowing or ambiguous edge conditions (e.g., due to occlusion, fog, or reflection interference), radar or camera sensor parameters can be dynamically adjusted (e.g., increasing the radar pulse rate or image exposure time) to improve boundary estimation accuracy. In another embodiment, redundant sensing modules (e.g., side cameras or ultrasonic sensors) can be deactivated when the confidence level of the reconstructed boundary exceeds a threshold to reduce power consumption while maintaining reliable road edge detection.

[0039] The level of autonomous driving and / or activation or deactivation of autonomous driving can be controlled based on features reconstructed using radar-based detection and image-assisted approximation of road boundaries. For example, when the reconstructed road boundary indicates a narrowing lane, a curved road, or missing boundary segments (e.g., due to rain, occlusion, or low reflectivity), the level of autonomous driving can be reduced, or manual driving can be temporarily requested. Conversely, a higher level of autonomous driving can be maintained when the reconstructed boundary is verified to be continuous and reliable (e.g., through consistent radar-image fusion confidence values). In another embodiment, if the system determines that the boundary detection quality has degraded beyond a threshold, autonomous driving can be deactivated, and a warning can be output to the driver via a display or audio alert. According to this disclosure, a vehicle and method for accurately processing road boundaries are provided even when sensor data is incomplete. While cost-effective, radar sensors can produce sparse point cloud data, resulting in gaps in boundary estimation. To address this issue, a processor analyzes radar-based point cloud data to identify static objects that define effective boundaries, such as guardrails, curbs, or cones, and generates virtual road boundaries by extending the detected boundaries. When an undetected area is identified, the processor determines whether the undetected area might contain undetected objects, and if so, connects the missing parts using static object data or past boundary information to form the final road boundary. Image sensor data can also be fused to refine the boundary where radar data is limited. Therefore, this disclosure enables reliable and continuous road boundary determination, improving the accuracy of autonomous driving with reduced sensor costs.

[0040] In the following description, embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0041] In the following text, reference will be made to Figures 1 to 3 Describe the vehicle that processes sensor trajectories.

[0042] Figure 1 An example is shown where a vehicle communicates with another device to send and receive data.

[0043] Reference Figure 1Vehicle 100 can be driven by either electricity or fossil fuels. In the case of electricity, vehicle 100 can be, for example, a pure battery-based vehicle driven solely by a high-voltage battery, or a gas-based fuel cell as its energy source. Furthermore, the fuel cell can use various types of gases capable of generating electricity (e.g., hydrogen, methane, ammonia, or biogas), and the gas can be, for example, filled into vehicle 100 in a liquefied state. Here, as an example, the gas can be hydrogen. However, the gas is not limited to this, and various gases can be used. In the case of fossil fuels, vehicle 100 is driven by fuels such as gasoline, diesel, or liquefied gas, and can be equipped with an internal combustion engine that drives actuator 114 through fuel combustion. From the perspective of providing driving rotational force to the wheels, the engine can be included in power source unit 112. As another embodiment, vehicle 100 can selectively utilize energy from a fossil fuel-based internal combustion engine and an electric battery to drive actuator 114, which can be a hybrid type vehicle (e.g., plug-in hybrid, mild hybrid, or series hybrid, etc.).

[0044] Vehicle 100 can refer to a mobile device. Vehicle 100 is a ground vehicle that travels on the ground and can be a conventional passenger car or commercial vehicle, purpose-built vehicle (PBV), etc. Vehicle 100 can be a four-wheeled vehicle, such as a passenger car, SUV, or light truck, or it can be a vehicle with more than four wheels, such as a bus, large truck, container truck, or heavy equipment vehicle (e.g., forklift, dump truck, or construction crane). Vehicle 100 can be a robot in a broad sense, such as a mobile device, and the robot can move using wheels, tracks, or other mobile modules (e.g., tracks, omnidirectional wheels, or leg actuators).

[0045] Vehicle 100 can be controlled to be driven manually by a user or through autonomous driving. Autonomous driving can be implemented as semi-autonomous or fully autonomous driving. Fully autonomous driving can be provided as autonomous driving, where the processor 118 of vehicle 100 has complete control, requiring no user intervention even when driving conditions are uncertain (e.g., complex urban intersections, unexpected pedestrian crossings, or tunnel entrance conditions). Semi-autonomous driving can be provided as autonomous driving that requires driver intervention depending on specific driving conditions (e.g., inclement weather, road construction zones, or sensor degradation). Semi-autonomous driving can be implemented such that when the above situations occur, the processor 118 disengages autonomous driving and transfers control to the user, allowing the user to perform manual driving. According to the levels of autonomous driving defined by the Society of Automotive Engineers (SAE), semi-autonomous driving can correspond to autonomous driving levels 1 to 4, and fully autonomous driving can correspond to level 5.

[0046] Vehicle 100 can communicate with other devices or with another vehicle 400. Other devices may include, for example, a server 200 supporting various controls, status management, and driving functions of vehicle 100; an Intelligent Transportation System (ITS) device 300 for receiving information from an intelligent transportation system; and various types of user equipment (e.g., smartphones, wearable devices, or in-vehicle infotainment terminals). Server 200, for example, is an external device operated by the vehicle manufacturer or provided to support driving functions, and can receive connection data from vehicle 100 or send necessary data for manual and automatic driving. In response to requests and data sent from vehicle 100 and user equipment, server 200 can send various information and software modules for controlling vehicle 100 to support driving and various services (e.g., navigation updates, remote diagnostics, or over-the-air firmware upgrades).

[0047] The ITS device 300 is, for example, a roadside unit (RSU), and can exchange vehicle identification data, driving control and status data, environmental data around the vehicle, map data, etc. with vehicle 100 via V2I to assist the user in driving the vehicle or support the autonomous driving of vehicle 100 (e.g., by providing traffic light status, construction warnings, or real-time congestion information). Vehicle 100 can exchange the above-listed data with another vehicle 400 via V2V to support manual or autonomous driving (e.g., for collision avoidance, cooperative lane merging, or platooning).

[0048] Vehicle 100 can communicate with other vehicles or other devices based on cellular communication, wireless access in the vehicle environment (WAVE) communication, dedicated short-range communication (DSRC) or near-field communication or other communication solutions (e.g., Wi-Fi Direct, Bluetooth or UWB communication).

[0049] For example, vehicle 100 can use cellular communication networks such as LTE or 5G, WiFi communication networks, or WAVE communication networks (e.g., IEEE 802.11p or IEEE 802.11bd) to communicate with server 200, ITS device 300, and another vehicle 400. In another embodiment, DSRC or similar technologies used in vehicle 100 can also be used for communication between vehicles. The communication methods between vehicle 100, server 200, ITS device 300, and another vehicle 400 or user equipment can include any combination of wired or wireless solutions (e.g., fiber optic cables, millimeter-wave links, or satellite relays), and are not limited to the foregoing embodiments.

[0050] Figure 2 Exemplary modules constituting a vehicle according to embodiments of this disclosure are shown.

[0051] The vehicle 100 may include a sensor unit 102, an operation unit 104, a display 106, a load device 108, and a communication unit 110.

[0052] The sensor unit 102 may include various types of sensors (e.g., road conditions, nearby objects, driver posture, or cabin temperature, etc.) for sensing various states and conditions occurring in the external surrounding environment, internal systems, user operations, and passenger space of the vehicle 100.

[0053] Specifically, the sensor unit 102 may include an image sensor 102a, a radar sensor 102b, etc., facing outward, in order to identify dynamic and static objects (e.g., pedestrians, vehicles, traffic signs, or curbs) around the vehicle 100.

[0054] Image sensor 102a can generate image data by recognizing external objects as images during use of vehicle 100 and send the image data to processor 118. Image sensor 102a may be referred to as a first sensor in this disclosure. At least one image sensor 102a may be mounted on a specific part of vehicle 100, such as the front, rear, or side of vehicle 100 (e.g., a front-view camera, a rear-view camera, or a side-view surround-view camera, etc.). When multiple image sensors 102a are mounted on each part, it may be referred to as a multi-camera system in this disclosure. Image data obtained by multiple image sensors 122a may be referred to as multi-view image data (e.g., a panoramic view, a bird's-eye view, or a 360-degree surround-view view, etc.). Although not shown, sensor unit 102 may also include a camera facing the interior of vehicle 100 (e.g., a driver monitoring camera or a passenger detection camera, etc.).

[0055] Radar sensor 102b can emit radio waves of a specific frequency around vehicle 100, generating radar data by transmitting radio waves reflected from external objects, thereby determining the presence and relative distance, speed, direction, etc., of external objects (e.g., other vehicles, obstacles, guardrails, or cyclists). Radar sensor 102b may be referred to as a second sensor in this disclosure. Furthermore, radar sensor 102b in this disclosure can be a heterogeneous sensor of a different type from image sensor 102a, identifying objects in a manner different from image sensor 102a (e.g., by detecting radio wave reflection intensity or Doppler shift, etc.).

[0056] In this disclosure, a lidar sensor (not shown) is shown without it installed, but in another embodiment, the lidar sensor may be mounted on vehicle 100. The lidar sensor can generate point cloud data as identification data for external objects and send the point cloud data to a processor to generate at least three-dimensional spatial information that identifies the shape of the external object (e.g., buildings, road boundaries, or traffic cones). The lidar sensor may be a heterogeneous sensor type different from the image sensor 102a.

[0057] Sensor unit 102 may include attitude sensor 102c. Attitude sensor 102c can detect, for example, the three-axis states of vehicle 100, such as yaw, pitch, and roll, and output various attitude states of the vehicle based on these factors (e.g., tilting on a slope, cornering motion, or vehicle body vibration). Attitude sensor may include, for example, IMU sensor, gyroscope sensor, etc. (e.g., accelerometer or magnetometer). Processor 118 can generate attitude data based on attitude states.

[0058] In addition, sensor unit 102 may include a positioning sensor 102d for confirming the location of vehicle 100. Positioning sensor 102c is, for example, a GPS sensor or a GNSS sensor (e.g., GLONASS, Galileo, or BeiDou), but is not limited thereto.

[0059] Furthermore, despite Figure 1 As not shown, sensor unit 102 may include a brake sensor and wheel sensors. The brake sensor detects the degree of braking of the brakes (e.g., brake pressure, pedal travel, or brake pad temperature), and the wheel sensors may detect, for example, wheel speed, wheel rotation angle, and wheel rotation angular velocity (e.g., using a Hall sensor, optical encoder, or magnetoresistive sensor). This disclosure primarily describes the sensors of sensor unit 102 mentioned in the embodiment description, but may further include sensors for sensing various conditions not listed herein (e.g., rain sensor, temperature sensor, ultrasonic sensor, or tire pressure sensor, etc.).

[0060] The operating unit 104 can be configured as a module for user-controlled driving. For example, the operating unit 104 may include a steering wheel for manual driving, automatic or manual transmission actuators, accelerator pedal, brake pedal, transmission, etc. (e.g., joystick control, paddle shifters, or a touch-based driving selector). The operating unit 104 also includes an interface for user-requested use, release, and detailed function selection of autonomous driving modes, allowing the user to utilize autonomous driving functions (e.g., lane keeping mode, adaptive cruise control, or automatic parking). The operating unit 102 can be configured, for example, as a hard interface located at a predetermined location within the vehicle 100, or as a touch-sensitive soft interface on the display 106, to receive various requests related to autonomous driving.

[0061] Display 106 can be used as a user interface. Display 106 can be used by processor 118 to display the vehicle 100's operating status, control status, route / traffic information, remaining energy information, driver requests, etc., for output (e.g., navigation maps, sensor visualizations, or infotainment content). Furthermore, display 106 can be configured as a touchscreen capable of detecting driver input and can receive driver requests instructing processor 118 (e.g., route selection, destination input, or system setting adjustments).

[0062] Communication unit 110 can support mutual communication with server 200, ITS device 300, surrounding vehicles 400, etc. (e.g., via V2V, V2I, or V2X communication). For example, communication unit 110 may include modules for processing cellular communication, WAVE, DSRC communication, etc. In this disclosure, transmitting / receiving unit 116 can transmit data generated or stored during driving to server 200 in signal form, and receive data and software modules transmitted from server 200 in specific types of signals (e.g., over-the-air updates, map data, or diagnostic codes).

[0063] Communication unit 110 can support the use of in Figure 2 Communication between components (e.g., between processor 118, operation unit 104, or sensor unit 102, etc.) to send or receive signals related to data, control, commands, and requests. These components may be, for example, Figure 2 The devices or modules indicated by reference numerals 102 to 118 in the accompanying drawings are shown. Communication unit 110 transmits signals between components, such as signals related to data, control, commands, and requests, to a communication bus via Controller Area Network (CAN) communication, and can send signals to specific components. The data, control, commands, and requests transmitted via CAN communication can be referred to as CAN data (e.g., steering commands, braking requests, or sensor fusion data).

[0064] The communication unit 110 can support communication with electronic devices carried by passengers within the vehicle 100 (e.g., smartphone pairing, wearable device synchronization, or wireless charging handshake). In this disclosure, the vehicle 100 can send and receive data utilized in the method according to this disclosure to the outside via the communication unit 110.

[0065] The vehicle 100 may also include a power source unit 112 and an actuator 114.

[0066] The power source unit 112 can generate and provide power and electricity for driving the power system and non-driving power systems, such as actuator 114. The non-driving power system can be, for example, sensor unit 102, operation unit 104, display 106, load device 108, communication unit 110, etc., but is not limited thereto, and may include various components (e.g., lighting, HVAC, or infotainment systems, etc.) that realize sensing, interface, communication, and convenience functions, in addition to components directly involved in driving operation.

[0067] When vehicle 100 is electrically powered, power source unit 112 may be, for example, an externally charged electric battery, or may be configured as a combination of an electric battery and a fuel cell that charges the battery (e.g., a lithium-ion battery combined with a hydrogen fuel cell, etc.). In the case of an electric battery and a fuel cell combination, power source unit 112 may include a tank for storing materials used to generate electricity from the fuel cell, such as liquefied hydrogen (e.g., in cryogenic or high-pressure form, etc.). When vehicle 100 may be fossil fuel powered, power source unit 112 may include an internal combustion engine. Furthermore, when vehicle 100 is a hybrid type, power source unit 112 may be provided by a combination of an internal combustion engine and an electric battery (e.g., a parallel hybrid or series-parallel hybrid configuration, etc.).

[0068] Actuator 114 includes at least one module for implementing driving operations and can perform driving operations based on signals from a user request from operating unit 104 or according to a request from processor 118. The requested signals may be associated with at least one of longitudinal control (such as acceleration and deceleration), lateral control (such as steering), and gear shifting (e.g., throttle control, regenerative braking, or automatic shifting). Here, gear shifting can be performed by the transmission at the request of a manual driving user or by processor 118 in autonomous driving.

[0069] Actuator 114 may include a wheel drive unit, mechanical components for performing driving operations on the wheel drive unit, and electronic modules to perform driving operations (e.g., electronic throttle, electric power steering, or brake-by-wire modules, etc.) depending on commands from processor 118, either manually or automatically by the user. When vehicle 100 operates on electric power, it may include components for transmitting requested driving operations to the wheel drive unit. When vehicle operates on fossil fuel power, actuator 114 may include a transmission and gear module (e.g., torque converter, clutch assembly, or multi-speed automatic transmission, etc.) for transmitting power from the internal combustion engine.

[0070] The wheel drive unit may include multiple wheels, a drive force generation module for generating and applying driving force to the wheels or transmitting driving force, a braking module for decelerating the wheels, and a steering module for achieving lateral control of the wheels (e.g., rack and pinion, steer-by-wire, or rear-wheel steering). When the vehicle 100 is powered by electric energy, the drive force generation module may be configured as a motor assembly (e.g., induction motor, permanent magnet motor, or hub motor) that generates driving force based on power output from an electric battery. When the vehicle is powered by fossil fuels, the drive force generation module may be an engine or transmission assembly. The braking module of the electric vehicle 100 may also have regenerative braking functionality (e.g., converting kinetic energy into battery charging during deceleration).

[0071] The vehicle 100 may also include a memory 116 and a processor 118.

[0072] The memory 116 may store applications and various data for controlling the vehicle 100, to load applications or read and write data when requested by the processor 118. In this disclosure, the memory 116 may include, according to embodiments of this disclosure, an application that tracks radar object data associated with objects detected from radar sensor 102b and processes road boundaries based on that data (e.g., to identify lane edges, guardrails, or curbs, etc.).

[0073] Radar object data may include regions based on point cloud data obtained by radar sensor 102b. This region may be provided as having boundaries surrounding objects identified from the point cloud data (e.g., vehicles, walls, or traffic barriers). Trajectories are included in trajectory information, and in this disclosure, trajectory information may be described interchangeably with radar trajectory information to distinguish it from other terms. Radar trajectory information may include, for example, trajectory region, trajectory identifier, object position, object velocity, object orientation angle, object type (or category), and the reliability of object estimation, the number of times the trajectory is maintained (e.g., persistence value, history index, or frame count, etc.).

[0074] The application may include processing to perform specific processing on point cloud data to generate new radar trajectories, and processing to predict the state of objects based on radar trajectory information from previously generated radar trajectories (e.g., using Kalman filtering, particle filtering, or motion extrapolation). Furthermore, the application may include processing for determining the location of the new radar trajectory, specifically the location of the object on which the trajectory is situated. The application can generate perceived road boundaries from static objects identified as road boundaries (e.g., curbs, guardrails, or roadside fences) perceived by radar sensor 102b.

[0075] The application can generate a final road boundary, for example, by estimating the shape of the final road boundary based on an analysis between a perceived road boundary sensed by radar sensor 102b and a sensed static object far from the perceived road boundary (e.g., where a curb section ends but the guardrail continues). As another embodiment, the application can generate a final road boundary by estimating its shape based on an analysis between a previous final road boundary and a far-away static object. The previous final road boundary can be estimated based on point cloud data acquired by radar sensor 102b at a previous time (or earlier). Details of the above estimation and generation will be described below.

[0076] The application may include a process of associating trajectories by identifying the similarity between new radar trajectories and existing trajectories using the results of the prediction process and correlation conditions between the trajectories (e.g., distance thresholds, velocity similarity, or angular alignment). Furthermore, the application may include processes such as assigning new trajectory identifiers based on the results of the association process, or maintaining or deleting trajectories (e.g., removing missing trajectories, merging overlapping trajectories, or updating IDs for persistent targets). The resulting final road boundary can be managed in each radar data acquisition cycle in the radar sensor 102b, such as each scan cycle (e.g., every 50 milliseconds, 100 milliseconds, or 200 milliseconds). This management may include maintaining, deleting, or altering the final road boundary.

[0077] Furthermore, the application may include a process that fuses image object data detected from image sensor 104a with radar object data during the association process (e.g., fusing bounding boxes, depth estimation, or object classification). The fused object data, i.e., the fused trajectory, can be used in the association process, and trajectory information for managing trajectory information can be provided based on the fused trajectory.

[0078] Processor 118 can perform overall control of vehicle 100. Processor 118 can be configured to execute applications and instructions stored in memory 116. Processor 118 can generate control-related signals for components of vehicle 100 based on driving control requests in manual and automatic driving modes. These components may be... Figure 2 At least one of the various components described herein. Processor 118 may include at least one of, for example, a central processing unit (CPU), a graphics processing unit (GPU), and a neural processing unit (NPU) (e.g., for real-time perception, object recognition, or control optimization, etc.). In another embodiment, processor 118 may act as a controller. The controller includes the aforementioned processing unit, cache memory, bus interface, etc., and may be, for example, an electronic control unit (ECU).

[0079] Processor 118 can execute various processes for generating and managing road boundaries based on point cloud data according to this disclosure (e.g., segmentation, clustering, or regression-based boundary extension, etc.). Point cloud data is described herein as being obtained from radar sensor 102b. However, unless technically contradictory, embodiments of this disclosure can also be applied to point cloud data obtained from lidar sensors (e.g., for higher resolution or redundancy-based detection, etc.).

[0080] Reference Figure 3 The processor 118 will be described as processing sensor data obtained from radar sensor 102b to generate and manage road boundaries. Figure 3 An example of generating and managing road boundaries based on sensor data is shown.

[0081] The processor 118 of vehicle 100 can perform preprocessing on radar data acquired from radar sensor 102b (e.g., point cloud data filtering, data clustering, or feature extraction, etc.). Here, radar data is taken as point cloud data, but preprocessing can include, for example, filtering to remove noise and outliers from the point cloud data, temporal alignment, spatial transformation of the trajectory identified by clustering the filtered point cloud data, synchronization with other sensor data, etc. (e.g., Kalman-based smoothing, ground removal, or DBSCAN clustering, etc.). Spatial transformation can include, for example, transforming the spatial data of the trajectory (e.g., coordinates) from the radar sensor coordinate system (e.g., polar coordinates relative to the radar sensor) to a coordinate system of a given viewpoint (e.g., a world space system or a vehicle fixed frame, etc.).

[0082] Clustering can include clustering point cloud data based on its distribution and distribution-related statistics to generate radar trajectories, and generating radar trajectory information (e.g., trajectory ID, centroid, or covariance) for each radar trajectory. Radar trajectories can be generated to represent objects estimated from the point cloud data (e.g., guardrail segments, vehicles, or traffic cones).

[0083] The processor 118 can generate a perceived road boundary (e.g., a detected road boundary) based on static objects (e.g., curb edges, guardrails, or lane-side barriers) that are identified as road boundaries in the radar trajectory.

[0084] The radar trajectory can include both static and dynamic objects perceived around vehicle 100. Static objects can include, for example, road infrastructure objects including traffic markings displayed on the road and road structures installed on / around the road. Road structures can be installed on the carriageway in a specific physical form (e.g., curbs, bollards, or barriers), as opposed to traffic markings printed on the lane. Dynamic objects can include, for example, other vehicles around vehicle 100, cyclists, animals, pedestrians, scooters, etc.

[0085] Traffic signs may include, for example, lanes, speed limits, arrows, directional signs, or stop lines. Road structures may include, for example, road boundaries, road signs, guardrails, traffic cones, traffic poles, crash barriers, or curbs. Road boundaries may be, for example, objects representing the road boundary used to distinguish road areas from non-road areas, or objects used to distinguish lanes (e.g., raised curbs, painted edge lines, or concrete dividers). Road structures used as road boundaries may include, for example, guardrails, cones, poles, barriers, and curbs.

[0086] Therefore, processor 118 can generate perceived road boundaries (e.g., detected road boundaries) based on trajectories identified as road boundaries in trajectories associated with road structures on the road.

[0087] Processor 118 can perform a process of generating a virtual road boundary based on an effective road boundary including at least a sensed road boundary (e.g., extending the detected road boundary using regression line information). Processor 118 can perform a process of determining whether to adopt a static object as a boundary candidate based on an approximation of the virtual road boundary and a static object spaced apart from the effective road boundary by radar sensor 102b (or a first sensor). Based on the adoption of the static object as a boundary candidate, processor 118 can determine whether the unsensitized area of ​​radar sensor 102b between the sensed road boundary and the boundary candidate on the effective road boundary is estimated to be in a presence-non-detection state. A presence-non-detection state can refer to a state in which an object is estimated to exist in the surrounding environment but is not detected by radar sensor 102b (e.g., due to occlusion, low reflectivity, or grazing angle incidence). A presence-non-detection state may be referred to as a false negative state in this disclosure. Based on the estimation that the unperceived area is in a state of existence but not detection, processor 118 can execute a process for estimating (or generating) a final road boundary based on the perceived road boundary and static object (e.g., by connecting the detected boundary and the boundary line associated with the static object). The generated final road boundary can be included in road boundary information that includes the trajectory information described above (e.g., with timestamps, confidence levels, or version IDs, etc.).

[0088] For dynamic objects, processor 118 may include processing to predict the object's state based on radar trajectory information from previously generated radar trajectories (e.g., constant speed or constant turning rate prediction, etc.). Furthermore, processor 118 may update the predicted state. Specifically, processor 118 may correct the predicted state using actual measurements or detections obtained from radar sensor 102b, for example (e.g., through measurement updates or gating tests, etc.).

[0089] Processor 118 can perform an interactive process of associating a previously estimated final road boundary from a previous trajectory with a final road boundary generated in a new trajectory to determine the identity between the previous and new trajectories (e.g., using overlap rate, Hausdorff distance, or ICP-based alignment). Here, the final road boundary can refer to road boundary information. The association process can also be performed on trajectories associated with dynamic objects (e.g., vehicle-to-vehicle trajectory continuity).

[0090] Processor 118 may include processes for reassigning trajectory identifiers or maintaining or deleting trajectories based on the results of associated processes (e.g., creation, update, or deletion operations). For example, processor 118 may manage road boundary information associated with the final road boundary (e.g., persistence, aging, or conflict resolution). When a trajectory is maintained, the trajectory information of associated trajectories can be reflected in and updated in the existing trajectory. When a target object disappears from the area of ​​interest of sensor unit 102, and a particular trajectory does not match the trajectory information of an existing trajectory for a period of time, the existing trajectory can be deleted (e.g., after N consecutive errors exceeding a predetermined waiting time).

[0091] The processor 118 can control the vehicle 100 (e.g., lane keeping, collision avoidance, or path replanning) based on road boundary information and trajectory information of dynamic objects. For example, the processor 118 can control the autonomous driving of the vehicle 100 based on road boundary information. Specifically, the processor 118 can establish a driving path based on road boundary information and control the actuator 114 based on driving path-based control signals (e.g., steering angle, longitudinal acceleration, or gear selection).

[0092] In another embodiment, the image data used in trajectory localization determination can also be used for association and trajectory information management. In the association process, processor 118 can fuse the image trajectory identified in the image data and the new radar trajectory into a common space, associate the image and radar trajectories in the common space, and output the fused trajectory information (e.g., through external calibration and projection onto a shared coordinate system, etc.). The image trajectory and radar trajectory may, for example, include perceived road boundaries. Fusion can be performed by matching objects detected at each sensor 102a, 102b, associating / projecting the matched objects using the geometric parameters of each sensor 102a, 102b, and calibrating the two trajectory information (e.g., using reprojection error, bundle adjustment, or synchronization timestamps, etc.). The fused trajectory information may include data that is at least substantially the same as the radar trajectory information. Processor 118 can use the fused trajectory information to manage trajectory information and control vehicle 100, such as actuator 114, based on the fused trajectory data.

[0093] Processor 118 is shown in this disclosure as configured as a single processing module. In another embodiment, processor 118 may be distributed across multiple processing modules, and the above processing may be performed by a distributed processing model (e.g., domain controller, edge ECU, or centralized computing, etc.).

[0094] Figure 4 Exemplary modules constituting a server according to this disclosure are shown.

[0095] Server 200 can send response data to vehicle 100 according to the request of vehicle 100, and can also send applications built into vehicle 100 and information for supporting vehicle driving (e.g., navigation map data, real-time traffic information, or remote control commands). Server 200 may include communication unit 202, memory 204, and processor 206.

[0096] The communication unit 202 can send and receive data to and from external devices, supports mutual communication with the vehicle 100 in this disclosure, and can exchange data with the vehicle 100 (e.g., vehicle status reports, diagnostic data, or over-the-air software updates).

[0097] The memory 204 can store applications and various data used to operate the server 200, and can load applications or read and write data according to requests from the processor 206. In this disclosure, the memory 204 can manage data and software related to models embedded in the vehicle 100 for processing sensor trajectories, such as trajectories based on radar sensor 102b (e.g., object classification weights, regression coefficients, or neural network parameters, etc.).

[0098] Processor 206 can perform overall control over server 200. Server 200 can be configured to execute applications and instructions stored in memory 204. Processor 206 executes applications to process and respond to user requests sent from vehicle 100 (e.g., data synchronization, service authentication, or fleet-level analysis).

[0099] Processor 206 is shown in this disclosure as configured as a single processing module. In another embodiment, processor 206 may be distributed across multiple processing modules, and the above processing may be performed by a distributed processing model (e.g., cloud computing cluster, edge gateway, or hybrid edge cloud architecture, etc.).

[0100] In the following text, reference will be made to Figure 5 A method for processing road boundaries according to another embodiment of the present disclosure is described in detail. Figure 5 An exemplary method for processing road boundaries is shown according to another embodiment of this disclosure. Figure 5 The methods described in the document can be executed with Figure 3 The estimation and generation of the final road boundary are related to processing (e.g., extrapolation, fusion, or time-consistent updates).

[0101] The method disclosed herein is executed by processor 118, but for ease of description, processor 118 and vehicle 100 may be described interchangeably. Although the sensor generating point cloud data is described in this disclosure as radar sensor 102b, processing of road boundaries based on point cloud data from a lidar sensor may also be used according to embodiments of this disclosure, provided there are no technical inconsistencies (e.g., higher density lidar data for redundancy or verification).

[0102] Reference Figure 5 In step S105, processor 118 can generate a virtual road boundary based on the effective road boundary generated from point cloud data of a first sensor detecting the environment surrounding vehicle 100. The first sensor in this disclosure is radar sensor 102b, and for ease of description, the first sensor can be described as radar sensor 102b.

[0103] Radar sensor 102b can generate point cloud data for detecting both static and dynamic objects (e.g., vehicles, curbs, barriers, or guardrails). The following description primarily focuses on the points representing static objects in relation to radar sensor 102b. Radar object data related to dynamic objects is described in [reference needed]. Figures 1 to 3 The description will be provided, and its processing will be omitted.

[0104] Static objects can be, for example, road structures that are installed on the road in a predetermined physical form and spatially distinct from the road (e.g., curbs, cones, or fences). In addition to road structures, static objects can also include various objects fixed to the road and having a physical form (e.g., lampposts, signs, or road markers). The processor 118 can identify road boundaries based on point cloud data associated with the road structures using an object detection model. The object detection model can be, for example, a machine learning or deep learning-based model (e.g., convolutional neural networks, support vector machines, or point-based segmentation models), and can identify road boundary objects based on trajectories associated with the road structures (see...). Figure 6 504 in the context of road boundary objects. Road boundary objects 504 can be, for example, guardrails, cones, poles, barriers, curbs, or linear medians, etc. Figure 6 Object 504 at the road boundary is shown as a guardrail.

[0105] Processor 118 can generate a perceived road boundary based on road boundary objects 504 detected and effectively identified by radar sensor 102b. The perceived road boundary can refer to a road boundary effectively identified from point cloud data (e.g., after thresholding or regression fitting). For example, processor 118 can generate a perceived road boundary 508 with regression line information, such as... Figure 6 As shown. Figure 6An embodiment of a virtual road boundary is illustrated. The regression line information can be information describing the line of the perceived road boundary 508 estimated based on point cloud data 506. For example, the regression line information can have an equation describing the line passing through point cloud data 506 by performing regression analysis (e.g., linear, quadratic, or piecewise polynomial, etc.) on the point cloud data 506. This equation can be, for example, a quadratic polynomial. The perceived road boundary is generated as a line of finite length and can include point information of the line's endpoints (e.g., start and end coordinates, slope and intercept, etc.). The point information can include the coordinates of the endpoints in two-dimensional space according to the equation of the regression line information, such as... Figure 6 As shown.

[0106] like Figure 6 As shown, processor 118 can generate an estimated boundary line 510 (e.g., another curb segment or roadside barrier, etc.) based on point cloud data of a static object perceived as being far from the perceived road boundary 508. This static object can be a road boundary object 504 or an object outside the road boundary. Therefore, processor 118 can identify a road boundary or another object based on the static object. In this disclosure, according to the above perspective, a static object far from the perceived road boundary 508 can be described as an object not limited to a specific type. The estimated boundary line 510 is generated with the same regression line information and point information as the perceived road boundary 508, and a detailed description of the regression line information and point information in the estimated boundary line 510 will be omitted.

[0107] Processor 118 can determine valid road boundaries based on at least perceived road boundaries 508. Specifically, processor 118 can determine valid road boundaries to include at least one of the perceived road boundaries 508 (e.g., previously generated in a previous scan frame) and a previous final road boundary. The previous final road boundary may be in Figure 5 The final road boundary generated in step S120 or S125. Here, "previous" can mean the time before the radar sensor 102b acquires the point cloud data in step S105. Therefore, the previous final road boundary can be generated based on the point cloud data acquired before the scanning timing of the radar sensor 102b associated with step S105. The previous final road boundary is generated with the same regression line information and point information as the perceived road boundary 508, and a detailed description of this information will be omitted below for ease of description. Figure 6 The reference numeral 508 indicating the perceived road boundary can be referred to as the effective road boundary. Figure 6 In other accompanying drawings, reference numeral 508 may also refer to the effective road boundary.

[0108] The processor 118 can use regression line information based on the effective road boundary 508 to generate a virtual road boundary 512 extending from the effective road boundary 508, such as... Figure 6 As shown (e.g., for predicting unobserved portions or occluded road edges, etc.). The virtual road boundary 512 can extend from the points at both ends of the finite effective road boundary 508 and be set in two-dimensional space. The virtual road boundary 512 can be generated to have the same regression line information as the effective road boundary 508 (e.g., sharing slope, curvature, and directional parameters, etc.).

[0109] Figure 7 An example of a virtual road boundary is shown.

[0110] The processor 118 can generate a first virtual road boundary based on sensor data from a first sensor and a first effective road boundary, and generate a second virtual road boundary based on sensor data from a second sensor and a second effective road boundary (e.g., radar-image fusion for multi-sensor road edge prediction). The first and second sensors can be a radar sensor 102b and an image sensor 102a, and the data from each sensor can be point cloud data and image data (e.g., radar reflectivity maps and lane edge pixel maps). Figure 7 In this diagram, only the second virtual road boundary 520 is shown, while the first virtual road boundary is not shown. The first virtual road boundary can be... Figure 6 The virtual road boundary 512 shown is... Figure 6 Virtual road boundaries can be Figure 7 Provided together with the second virtual road boundary 520 in the two-dimensional space shown, to form the first virtual road boundary 512 (e.g., a composite lane edge representation, such as left and right road edges, inner and outer boundaries, or lane dividers). Therefore, the virtual road boundary can be generated to include the first virtual road boundary 512 and the second virtual road boundary 520. The first virtual road boundary 512 can be generated based on a first effective road boundary, which includes at least one of a sensed road boundary 508 and a previous final road boundary, such as... Figure 6 As shown.

[0111] Regarding the generation of the second virtual road boundary 520, the processor 118 can generate a perceived road boundary 518 based on road boundary objects 504 detected and effectively identified by the image sensor 102a (e.g., through edge extraction, lane marking detection, or boundary segmentation). The perceived road boundary 518 can refer to a road boundary effectively identified from image data. For example, the processor 118 can generate a perceived road boundary 518 with regression line information, such as... Figure 7As shown (e.g., slope, curvature, and offset parameters, etc.). The regression line information can be information describing the line of the perceived road boundary 518 estimated based on image data. For example, the regression line information can have an equation describing the line near the road boundary object by performing regression analysis (e.g., least squares fitting, RANSAC fitting, or polynomial regression, etc.) on the perceived road boundary object 504 in the image data. This equation can be, for example, a quadratic polynomial. The perceived road boundary 518 is generated as a line of finite length and can include point information of the two endpoints of the line (e.g., start and end coordinates or boundary pixel pairs, etc.). The point information can include the coordinates of the two endpoints in two-dimensional space according to the regression line information equation, such as... Figure 7 As shown.

[0112] Processor 118 can determine a second effective road boundary based on the perceived road boundary 518. In the following description, for ease of description, reference numeral 518 may be referred to as the second effective road boundary. Processor 118, as... Figure 7 As shown, a second virtual road boundary 520 extending from the second effective road boundary 518 can be generated using regression line information based on the second effective road boundary 518 (e.g., an extrapolation or occluded area extending outside the camera's field of view). The second virtual road boundary 520 can extend from points at both ends of the finite second effective road boundary 518 and is positioned in a two-dimensional space. The second virtual road boundary 520 can be generated with the same regression line information as the second effective road boundary 518 (e.g., the same slope, curvature, and confidence weights).

[0113] According to this disclosure, the first virtual road boundary 512 is generated based on a first effective road boundary 512 based on sparse point cloud data (e.g., low-density radar reflections or coarse object outlines, etc.), and boundary estimation of the road boundary object 504 may not be guaranteed. Image object data associated with the road boundary object 504 detected by image data can achieve boundary estimation of the road boundary object 504 (e.g., fine pixel-level edge depiction or lane line curvature refinement, etc.). For example, the second virtual road boundary 520 may have higher boundary estimation characteristics than the first virtual road boundary 512 due to higher spatial resolution or visual semantic accuracy.

[0114] Figure 8 An example of a virtual road boundary is shown.

[0115] The second virtual road boundary 524 can be generated to extend into the detection range of the first sensor (e.g., radar sensor 102b), which is larger than the detection range 522 of the second sensor (e.g., image sensor 102a) (e.g., radar range ≈ 200 meters vs. camera ≈ 80 meters, etc.). The detection range of image sensor 102a is smaller than that of radar sensor 102b, and therefore it may not be able to detect static objects (e.g., distant guardrails, poles, or distant barriers, etc.) perceived by radar sensor 102b as separated from the effective road boundary 518. Figure 5 In step S110, the second virtual road boundary 524 used when determining approximation to a static object does not extend to the static object, which may prevent approximation judgment processing. Correspondingly, even when the detection range 522 of the image sensor 102a does not reach the static object, the second virtual road boundary 524 extends to the detection range of the radar sensor 102b, thereby allowing approximation judgments to be processed normally (e.g., extrapolating the camera boundary using the geometry derived from the radar).

[0116] Reference Figure 5 In S110, the processor 118 can determine whether to adopt the static object as a boundary candidate based on the approximation of the virtual road boundary and a static object (e.g., a cone, fence, or wall detected outside the lane markings) perceived by the radar sensor 102b as being spaced apart from the effective road boundary.

[0117] according to Figure 6 In one embodiment, the processor 118 may determine whether to select the static object as a boundary candidate based on the approximation of the virtual road boundary 512 generated by the radar sensor 102b and the static object perceived as being far from the effective road boundary 508.

[0118] For example, processor 118 can determine whether approximate conditions are met for the distances between points 514, 516 at both ends of an estimated boundary line 510 associated with a static object in two-dimensional space and the virtual road boundary 512 (e.g., within tolerance thresholds, such as ≤ 1.0 meter or ≤ 5° angular deviation, etc.). Since the virtual road boundary 412 includes equations based on regression line information, processor 118 can determine whether the distance d between point 516 at one end and the virtual road boundary 512 is less than or equal to a first reference distance, and whether the distance between point 514 at the other end and the virtual road boundary 512 is less than or equal to a second reference distance. The conditions associated with whether the distances between points 514, 516 at both ends are within the first and second reference distances can be approximate conditions. Although this disclosure shows approximate conditions using points 514, 516 at both ends, approximate conditions can also be set in different ways (e.g., midpoint deviation, average offset, or vertical projection error, etc.).

[0119] The processor 118 may select static objects and / or estimated boundary lines 510 as boundary candidates based on whether an approximate condition regarding the distance between the points 514, 516 at both ends and the virtual road boundary 512 is met (e.g., confirming geometric continuity between the curb segment and the predicted boundary). When the approximate condition is not met, the processor 118 may not use static objects and estimated boundary lines 510 as boundary candidates (e.g., when the lateral gap exceeds a threshold or a curvature mismatch occurs).

[0120] according to Figure 7 In another embodiment involving boundary candidate selection, processor 118 may use static objects and / or estimated boundary lines 510 as boundary candidates based on static objects satisfying approximation conditions with either the first virtual road boundary 512 or the second virtual road boundary 520 (e.g., radar-image boundary fusion with increased redundancy). The approximation conditions may be substantially the same as in the embodiments described above. According to another embodiment, the second virtual road boundary 520 may have a higher boundary estimate than the first virtual road boundary 512, thereby accurately selecting boundary candidates and robustly generating and processing the final road boundary without omitting static objects estimated as continuous road boundaries (e.g., at highway merging points, curved exits, or obscured corners).

[0121] Reference Figure 5 In step S115, the processor 118 of the vehicle 100 can determine, based on static objects (or estimated boundary lines 510) adopted as boundary candidates, whether an area undetected by the radar sensor 102b between the perceived road boundary and the boundary candidates on the effective road boundary is estimated to be in a state of presence and non-detection (e.g., for blind spot inference or occlusion bridging). A state of presence and non-detection means that an object not detected by the radar sensor 102b is assumed to actually exist in the surrounding environment, and can be referred to as a false negative state (e.g., due to radar reflection loss, rain attenuation, or visual occlusion).

[0122] like Figure 9 and Figure 10 As shown, the processor 118 can determine that the unsensitized region 528 is estimated to be in a state of presence and undetection based on the fact that the number of times the radar sensor 102b fails to detect subsequent real objects in the unsensitized region 528 of the radar sensor 102b is less than or equal to the absence state value (e.g., below a predefined confidence threshold or false negative limit). Figure 9 An embodiment related to determining the state of an unperceived region is shown. Figure 10 An embodiment related to determining the state of an unperceived region is shown.

[0123] Subsequent object failures can refer to situations where, after radar sensor 102b detects an object in step S105, the object in the surrounding environment is not actually detected during the radar sensor 102b's scan (e.g., a guardrail temporarily obscured by another vehicle or a cone hidden by rain clutter). For example, when radar sensor 102b detects the surrounding environment at multiple scan times while vehicle 100 is moving, data related to the presence or absence of objects in radar sensor 102b can be recorded for each scan time (e.g., frame-by-frame occupancy status or binary detection log). The number of subsequent object failures can be counted using data related to the presence or absence of detection recorded at each scan time (e.g., in 5-10 consecutive scans, depending on the radar frequency).

[0124] like Figure 9 As shown, data related to the presence or absence of subsequently undetected objects can be generated on a one-dimensional grid map 530 in a two-dimensional space with valid road boundaries 508 and estimated boundary lines 510, along one direction. For example, the one-dimensional grid map 530 has cells that record this data, and actual object detection can be indicated as 0, while actual object non-detection can be indicated as 1 (e.g., binary occupancy representation or temporal confidence decay, etc.). The processor 118 can identify cells in the one-dimensional grid map 530 corresponding to the undetected region 528 to determine whether the actual number of times an object is not detected is less than or equal to the absence state value (e.g., less than three consecutive non-detections trigger the presence hypothesis, etc.).

[0125] As another embodiment, such as Figure 10 As shown, data related to the presence or absence of subsequently undetected objects can be generated on a two-dimensional grid map 534 in a two-dimensional space containing valid road boundaries 508 and estimated boundary lines 510 (e.g., an occupancy grid or bird's-eye view map for environmental modeling). For example, the two-dimensional grid map 534 has cells that record data, and the actual detection of an object can be indicated as 0, while the actual absence of an object can be indicated as 1. The processor 118 can identify cells in the two-dimensional grid map 534 corresponding to the undetected area 528 to determine whether the actual number of times an object is not detected is less than or equal to a non-existent state value (e.g., < a threshold count indicating intermittently missed detections, etc.).

[0126] The processor 118 can determine that the undetected region 528 is in an absent-non-detection state based on the fact that the number of times an object is actually not detected exceeds the absence-state value (e.g., continuous detection loss during multiple scans). An absent-non-detection state refers to a state where not only is the object not detected by the radar sensor 102b, but the object is also estimated to actually not exist; this can be termed a true negative state (e.g., an empty lane divider, an unobstructed shoulder, or an open exit ramp). This can correspond to the undetected region 528 that is not estimated to be in an absent-non-detection state.

[0127] Reference Figure 5 In S120, the processor 118 can estimate static objects as road boundaries based on the state that the unperceived area 528 is estimated to be present and undetected, and generate the final road boundary (e.g., by fusing the curb edge predicted by radar with previously detected lane markings, etc.) based on the perceived road boundary and static objects.

[0128] like Figure 11 As shown, processor 118 can generate final road boundary 538 by merging static objects and perceived road boundaries (e.g., perceived road boundary 508) by connecting the road boundaries of static objects and perceived road boundaries (e.g., creating a continuous line between a guardrail segment and an existing lane boundary). Figure 11 An example related to the generation of the final road boundary is shown.

[0129] Reference Figure 5 In step S125, processor 118 can generate a final road boundary based on the perceived road boundary spaced apart from static objects and based on the state that the unperceived region 528 is estimated to be non-existent and undetected. For example, processor 118 can generate a final road boundary based on the perceived road boundary without incorporating static objects, based on the state that the unperceived region 528 is not estimated to be present and undetected (e.g., lane edges are uninterrupted and no roadside structure is inferred).

[0130] like Figure 12 As shown, processor 118 can generate final road boundary 540 based solely on perceived road boundaries (e.g., perceived road boundary 508) without estimating static objects as road boundaries (e.g., when roadside space is open or lacks physical structure). Figure 12 An embodiment related to the generation of the final road boundary is shown. The final road boundary 540 can be generated disconnected from static objects to match the estimated actual road boundary (e.g., aligned with detected lane markings or lane edge curvature, etc.).

[0131] Reference Figure 5The S130, in response to, except Figures 6 to 8 If, in addition to the static object shown, another static object is detected by radar sensor 102b, processor 118 can execute steps S105 to S125, and in response to the absence of another static object, processor 118 can terminate the processing of the final road boundary (e.g., once all candidate static objects within the detection range have been exhausted). When processing terminates, as... Figure 3 As shown, the final road boundary is processed into road boundary information through management processing, and the vehicle 100 can be autonomously controlled based on the road boundary information (e.g., lateral control, obstacle avoidance, or adaptive path following).

[0132] According to this disclosure, objects associated with road boundaries that are not perceived due to sensor performance limitations can be robustly estimated to conform to actual road boundary objects 504 (e.g., maintaining continuous edge detection despite the presence of occlusion, fog, or sparse reflective areas).

[0133] Figure 13 An exemplary computing system (e.g., a computing device for a vehicle or any other device) is illustrated. One or more controllers, processors, etc., described herein, such as one or more components of vehicle 100, one or more components of server 200, one or more components of another vehicle 400, and any other components and devices disclosed herein, can be provided by, for example, Figure 13 The computing system shown is implemented or implemented in the computing system.

[0134] The computing system 1000 may include at least one processor 1100, a memory 1300, a user interface input device 1400, a user interface output device 1500, a storage device 1600, and a network interface 1700 connected to each other via a bus 1200.

[0135] Processor 1100 may be a central processing unit (CPU) or a semiconductor device that processes instructions stored in memory 1300 and / or storage device 1600. Each of memory 1300 and storage device 1600 may include various types of volatile or non-volatile storage media. For example, memory 1300 may include read-only memory (ROM) and random access memory (RAM).

[0136] A communication interface (also known as a communication device, communicator, communication module, communication unit, etc.), such as a network interface 1700, allows software and / or data to be transmitted between the device and / or one or more external devices and / or components of the device. A communication interface may include a receiver, transmitter, transceiver, modem, network interface and / or adapter (e.g., an Ethernet adapter), radio transceiver, antenna, communication port, PCMCIA slot and card, etc. The software and data transmitted through the communication interface may be in the form of signals, which may be electronic, electromagnetic, optical, infrared, or other signals that can be received by the communication interface. These signals can be provided to the communication interface through the device's communication path, which may be implemented, for example, using wires or cables, optical fibers, cellular links, radio frequency (RF) links, and / or other communication channels. The communication interface can communicate using one or more communication protocols, such as Ethernet, Wi-Fi, Near Field Communication (NFC), Infrared Data Association (IrDA), Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Long Term Evolution (LTE), 5G New Radio (NR), Vehicle-to-Everything (V2X), Controller Area Network (CAN), or Local Interconnect Network (LIN).

[0137] Therefore, the operation of the methods or algorithms described in relation to the exemplary embodiments disclosed in the specification can be directly implemented by hardware modules, software modules, or a combination of hardware and software modules executed by processor 1100. Software modules can reside on storage media (e.g., memory 1300 and / or storage device 1600), such as RAM, flash memory, ROM, erasable programmable ROM (EPROM), electrically EPROM (EEPROM), registers, hard disk drives, removable disks, or optical disc-ROMs (CD-ROMs).

[0138] The storage medium can be coupled to the processor 1100. The processor 1100 can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor 1100. The processor and storage medium can be implemented using an application-specific integrated circuit (ASIC). The ASIC can be located in the user terminal. Alternatively, the processor and storage medium can be implemented as discrete components in the user terminal.

[0139] According to one embodiment of this disclosure, a method for processing road boundaries is provided, the method comprising: generating a virtual road boundary based on an effective road boundary generated from point cloud data of a first sensor detecting the environment surrounding a vehicle; determining whether to adopt the static object as a boundary candidate based on the approximation of the virtual road boundary and a static object perceived by the first sensor as being far from the effective road boundary; determining whether an unperceived area of ​​the first sensor between the perceived road boundary and the boundary candidate on the effective road boundary is estimated to be in a state of presence and undetection based on the static object being adopted as a boundary candidate; generating a final road boundary based on the perceived road boundary and the static object based on the estimation that the unperceived area is in a state of presence and undetection; and controlling the vehicle based on the final road boundary. The state of presence and undetection is an estimation of the presence of an object in the surrounding environment that is not detected by the first sensor.

[0140] For example, a valid road boundary may include at least one of a sensed road boundary and a prior final road boundary, wherein the sensed road boundary may be generated from point cloud data and identified as a valid road boundary, and the prior final road boundary may be a final road boundary generated based on point cloud data acquired at a previous time.

[0141] For example, virtual road boundaries can be generated by extending from valid road boundaries using regression line information based on valid road boundaries.

[0142] For example, determining whether to use a static object as a boundary candidate may include using the static object as a boundary candidate based on the fact that an approximate condition based on distance between the two endpoints of the estimated boundary line associated with the static object and the virtual road boundary is satisfied.

[0143] For example, the virtual road boundary may include a first virtual road boundary and a second virtual road boundary. The first virtual road boundary may be generated based on a first valid road boundary generated from point cloud data from a first sensor, and the second virtual road boundary may be generated based on a second valid road boundary generated from image data from a second sensor that detects the surrounding environment. Furthermore, determining whether to use a static object as a boundary candidate may include: using the static object as a boundary candidate based on the static object satisfying an approximation condition with either the first virtual road boundary or the second virtual road boundary.

[0144] For example, the second virtual road boundary can be generated by extending the detection range of the first sensor to a range greater than that of the second sensor.

[0145] For example, determining whether the undetected area of ​​the first sensor is estimated to be in a state of presence but not detection may include: determining that the undetected area is estimated to be in a state of presence but not detection based on the fact that the number of times the first sensor fails to detect subsequent actual objects in the undetected area is less than or equal to the non-existent state value.

[0146] For example, generating the final road boundary may include: estimating a static object as the road boundary; and generating a final road boundary that connects the road boundary of the static object and the perceived road boundary to merge the static object with the perceived road boundary.

[0147] For example, determining whether an unperceived area is estimated to be in a state of existence but not detection may include: determining that the unperceived area is in a state of non-existence and non-detection based on the fact that the unperceived area is not estimated to be in a state of existence but not detection. The state of non-existence and non-detection may be a state where an object is not detected by the first sensor and the object is estimated to actually not exist. The method may further include: generating a final road boundary based on the perceived road boundary based on the fact that the unperceived area is estimated to be in a state of non-existence and non-detection.

[0148] For example, perceived road boundaries can be identified by sensing road structures installed on the road in a predetermined form.

[0149] According to another embodiment of this disclosure, a vehicle is provided, comprising: a sensor unit including a first sensor for detecting the environment surrounding the vehicle; a memory storing at least one instruction; and at least one processor for executing the at least one instruction stored in the memory. The at least one processor is configured to: generate a virtual road boundary based on an effective road boundary generated from point cloud data from the first sensor; determine whether to adopt the static object as a boundary candidate based on the approximation of the virtual road boundary and a static object perceived by the first sensor as being far from the effective road boundary; determine whether an undetected area of ​​the first sensor between the perceived road boundary and the boundary candidate on the effective road boundary is estimated to be in a state of presence and undetection based on the static object being adopted as a boundary candidate; generate a final road boundary based on the perceived road boundary and the static object based on the estimation that the undetected area is in a state of presence and undetection; and control the vehicle based on the final road boundary. The state of presence and undetection is an estimation of the presence of an object in the surrounding environment that is not detected by the first sensor.

[0150] According to this disclosure, a method for robustly estimating objects associated with unperceived road boundaries under sensor performance limitations and a vehicle for processing road boundaries can be provided.

[0151] The effects that can be obtained in this disclosure are not limited to those described above, and other effects not mentioned will be clearly understood by those skilled in the art to which this disclosure pertains from the following description.

[0152] Although the exemplary method described above according to this disclosure is represented as a series of operations for clarity of description, this is not intended to limit the order in which the steps are performed, and these steps may be performed simultaneously or in different orders if necessary. To implement the method according to this disclosure, the described steps may further include other steps, including remaining steps in addition to some steps, or may include additional steps in addition to some steps.

[0153] The various embodiments disclosed herein are not a list of all possible combinations, but are intended to describe representative embodiments of the present disclosure, and the matters described in the various embodiments may be applied independently or in combination of two or more.

[0154] Furthermore, various embodiments of this disclosure can be implemented in hardware, firmware, software, or a combination thereof. When implementing this disclosure in hardware, it can be implemented using application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, etc.

[0155] The scope of this disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) for enabling the operation of methods according to various embodiments to be executed on a device or computer, and non-transitory computer-readable media having such software or instructions stored thereon and executable on a device or computer.

Claims

1. A method performed by a vehicle, the method comprising the following steps: Point cloud data associated with at least one static object in the vehicle's surrounding environment is acquired via the vehicle's sensors; Based on the point cloud data, road boundaries are detected; Virtual road boundaries are generated by extending the detected road boundaries; Based on the approximation of the virtual road boundary with the at least one static object, it is determined whether to select the at least one static object as a boundary candidate, wherein the at least one static object is spaced apart from the detected road boundary; Determine whether an unperceived area is in a state of existence and non-detection, wherein the unperceived area is an area that is not detected by the sensor and is located between a detected road boundary and a boundary candidate, and wherein the state of existence and non-detection refers to the state in which an object that is not detected by the sensor is estimated to exist in the surrounding environment; Based on the detected road boundary, the at least one static object, and the undetected area being in the state of being present but not detected, a signal indicating the final road boundary is output; and Based on the signal, the vehicle is controlled to drive automatically.

2. The method according to claim 1, in, The detected road boundary includes at least one of the perceived road boundary and the previous final road boundary. The perceived road boundary is determined from the point cloud data and used as the detected road boundary. The aforementioned final road boundary is generated based on point cloud data acquired at a previous time.

3. The method according to claim 1, in, The virtual road boundary is generated by extending the detected road boundary using regression line information, and The regression line information is derived from the detected road boundaries.

4. The method according to claim 1, in, The step of determining whether to select the at least one static object as a boundary candidate includes: When the distance between the first point and the second point meets the threshold distance, at least one static object is selected as a boundary candidate. Wherein, the first point corresponds to the endpoint of the estimated boundary line associated with the at least one static object, and The second point corresponds to the endpoint of the virtual road boundary.

5. The method according to claim 1, in, The virtual road boundary includes a first virtual road boundary and a second virtual road boundary. The first virtual road boundary is generated based on a first detected road boundary determined from the point cloud data. The second virtual road boundary is generated based on a second detected road boundary determined by image data obtained from a second sensor configured to detect the surrounding environment; and The step of determining whether to select the at least one static object as a boundary candidate includes: selecting the at least one static object as a boundary candidate when the at least one static object satisfies the approximation condition of at least one of the first virtual road boundary and the second virtual road boundary.

6. The method according to claim 5, in, The second virtual road boundary is generated by extending the detection range of the second sensor to a range corresponding to the detection range of the sensor, wherein the detection range of the sensor is greater than the detection range of the second sensor.

7. A vehicle comprising: The sensor is configured to acquire point cloud data associated with at least one static object in the environment surrounding the vehicle. A drive control circuit is configured to control the automatic driving of the vehicle; as well as The processor circuitry is configured to cause the vehicle to: Based on the point cloud data, road boundaries are detected. Based on the regression line information derived from the detected road boundaries, virtual road boundaries are generated. Whether to select the at least one static object as a boundary candidate is determined based on whether the approximate conditions between the boundary line associated with the at least one static object and the virtual road boundary are met. Determining whether an undetected region is in a state of existence and non-detection, wherein the undetected region is a region not detected by the sensor and located between a detected road boundary and a boundary candidate, and wherein the state of existence and non-detection refers to the state in which an object is estimated to exist in the surrounding environment but not detected by the sensor. Based on the detected road boundary, the at least one static object, and the undetected area being in the state of being present but not detected, a signal indicating the final road boundary is output, and The vehicle's autonomous driving is controlled via the drive control circuit and based on the signal.

8. The vehicle according to claim 7, in, The regression line information is derived by fitting the regression line to multiple boundary points included in the detected road boundaries, and The virtual road boundary is generated by extending the regression line beyond the end of the detected road boundary.

9. The vehicle according to claim 7, in, The approximation condition is satisfied when the distance between the first point and the second point is less than or equal to a predetermined threshold distance. Wherein, the first point corresponds to the endpoint of the estimated boundary line associated with the at least one static object, and wherein, the second point corresponds to the endpoint of the virtual road boundary.

10. The vehicle according to claim 7, in, If the number of times the sensor fails to detect an object in the undetected area is less than or equal to a non-existent state threshold, the undetected area is determined to be in the state of being present but not detected.

11. A vehicle comprising: The sensor is configured to acquire point cloud data associated with at least one static object in the environment surrounding the vehicle. processor; as well as The memory stores at least one instruction, which, when executed by the processor, is configured to cause the vehicle to: Based on the point cloud data, road boundaries are detected. Virtual road boundaries are generated by extending the detected road boundaries. Based on the approximation of the virtual road boundary with the at least one static object, a determination is made as to whether to select the at least one static object as a boundary candidate, wherein the at least one static object is spaced apart from the detected road boundary. Determining whether an undetected region is in a state of existence and non-detection, wherein the undetected region is a region not detected by the sensor and located between a detected road boundary and a boundary candidate, and wherein the state of existence and non-detection refers to the state in which an object is estimated to exist in the surrounding environment but not detected by the sensor. Based on the detected road boundary, the at least one static object, and the undetected area being in the state of being present but not detected, a signal indicating the final road boundary is output, and Based on the signal, the vehicle is controlled to drive automatically.

12. The vehicle according to claim 11, in, The detected road boundary includes at least one of the perceived road boundary and the previous final road boundary. The perceived road boundary is determined from the point cloud data and used as the detected road boundary. The aforementioned final road boundary is generated based on point cloud data acquired at a previous time.

13. The vehicle according to claim 11, in, The virtual road boundary is generated by extending the detected road boundary using regression line information, and The regression line information is derived from the detected road boundaries.

14. The vehicle according to claim 11, in, When determining whether to select the at least one static object as a boundary candidate, the at least one instruction, when executed by the processor, is configured to cause the vehicle to: When the distance between the first point and the second point meets the threshold distance, at least one static object is selected as a boundary candidate. Wherein, the first point corresponds to the endpoint of the estimated boundary line associated with the at least one static object, and The second point corresponds to the endpoint of the virtual road boundary.

15. The vehicle according to claim 11, in, The virtual road boundary includes a first virtual road boundary and a second virtual road boundary. Wherein, the first virtual road boundary is generated based on a first detected road boundary determined from the point cloud data, and The second virtual road boundary is generated based on a second detected road boundary determined by image data obtained from a second sensor configured to detect the surrounding environment; and Specifically, when determining whether to select the at least one static object as a boundary candidate, the at least one instruction, when executed by the processor, is configured to cause the vehicle to: When the at least one static object satisfies the approximation condition of at least one of the first virtual road boundary and the second virtual road boundary, the at least one static object is selected as a boundary candidate.

16. The vehicle according to claim 15, in, The second virtual road boundary is generated by extending the detection range of the second sensor to a range corresponding to the detection range of the sensor, wherein the detection range of the sensor is greater than the detection range of the second sensor.

17. The vehicle according to claim 11, in, When determining whether the undetected area is in the state of presence and undetection, the at least one instruction, when executed by the processor, is configured to cause the vehicle to: Based on the fact that the number of times the sensor does not detect an object in the unperceived area is less than or equal to the absence state threshold, the unperceived area is determined to be in the presence and non-detection state.

18. The vehicle according to claim 11, in, The at least one instruction, when executed by the processor, is configured to cause the vehicle to: The at least one static object is identified as part of the road boundary, and The final road boundary is generated by connecting this portion of the road boundary with the detected road boundary, thereby merging the at least one static object with the detected road boundary.

19. The vehicle according to claim 11, in, When determining whether the undetected region is in the state of being present but not detected, the at least one instruction is configured, when executed by the processor, to: Based on the determination that the unperceived area is not in the "existence and undetected" state, it is determined that the unperceived area is in the "non-existence and undetected" state, wherein the "non-existence and undetected" state means that the object is not detected by the sensor and the object is determined to be actually non-existent. The final road boundary is generated based on the determination that the unperceived area is in a non-existent and undetected state and the detected road boundary.

20. The vehicle according to claim 11, in, The detected road boundaries are identified by detecting road structures installed on the road in a predetermined form in the environment surrounding the vehicle.

Images