Virtual vehicles for intersection edging and virtual stop lines

Abstract

At least one virtual road user is generated, and the position of each virtual road user corresponds to the boundary of the range of the host vehicle's sensors approaching the network intersection. The most relevant virtual road user among the at least one is determined and associated with the lane that will be crossed first at the intersection from the host vehicle's perspective. The time to contact for the most relevant virtual road user is determined, based on the host vehicle's acceleration, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant virtual road user. A target speed for the host vehicle is determined based on the time to contact and the relative distance. The host vehicle operates using the target speed.

Description

TECHNICAL FIELD

[0001] The present application relates generally to risk mitigation for autonomous driving vehicles, and more specifically to intersection edging and virtual stop lines during trajectory planning of autonomous driving vehicles. BACKGROUND ART

[0002] The increasing use of autonomous driving vehicles creates the possibility of more efficient movement of passengers and cargo through transportation networks. Furthermore, the use of autonomous driving vehicles may result in improved vehicle safety and more effective communication between vehicles. However, external objects make it difficult to navigate through transportation networks. SUMMARY OF THE INVENTION

[0003] Disclosed herein are aspects, features, elements, and implementations of proactive risk mitigation.

[0004] A first aspect of the disclosed implementations is a method comprising generating at least one virtual road user, wherein the position of each virtual road user of the at least one virtual road user corresponds to a boundary of a sensor range of a host vehicle approaching an intersection of a vehicle transportation network; determining the most relevant virtual road user among the at least one virtual road user, wherein the most relevant virtual road user is associated with the earliest traversable lane of the intersection from the perspective of the host vehicle; determining a time-to-contact for the most relevant virtual road user, wherein the time-to-contact is based on an acceleration of the host vehicle, a predicted trajectory of the most relevant virtual road user, and a relative distance between the host vehicle and the most relevant virtual road user; determining a target speed for the host vehicle based on the time-to-contact and the relative distance; and operating the host vehicle using the target speed as an input to a control system of the host vehicle.

[0005] A second aspect of the disclosed implementation is a device including a processor. The processor is configured to generate at least one virtual road user, the location of each of the at least one virtual road user corresponding to the boundary of the range of a host vehicle's sensors approaching an intersection of a traffic network; to determine the most relevant virtual road user among the at least one virtual road user, the most relevant virtual road user being associated with the first lane to be crossed at the intersection as seen from the host vehicle's viewpoint; to determine the time to contact for the most relevant virtual road user, the time to contact being based on the host vehicle's acceleration, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant virtual road user; to determine a target speed for the host vehicle based on the time to contact and the relative distance; and to operate the host vehicle using the target speed as input to the host vehicle's control system.

[0006] A third aspect of the disclosed implementation is a non-temporary computer-readable medium storing instructions that cause one or more processors to perform an operation, the operation comprising: generating at least one virtual road user, the location of each of the at least one virtual road user corresponding to the boundary of the range of sensors of a host vehicle approaching an intersection of a traffic network; determining the most relevant virtual road user of the at least one virtual road user, the most relevant virtual road user being associated with the first lane to be crossed at the intersection as seen from the viewpoint of the host vehicle; determining the time to contact for the most relevant virtual road user, the time to contact being based on the acceleration of the host vehicle, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant virtual road user; determining a target speed for the host vehicle based on the time to contact and the relative distance; and operating the host vehicle using the target speed as input to the host vehicle's control system.

[0007] These and other aspects of the present disclosure are disclosed in the following detailed description of embodiments, the appended claims, and the appended drawings. [Brief explanation of the drawing]

[0008] The disclosed technology will be best understood from the following detailed description, which should be read in conjunction with the accompanying drawings. It should be emphasized that, in accordance with common practice, various features of the drawings may not be to scale. Conversely, dimensions of various features may be enlarged or reduced as appropriate for clarity. Furthermore, unless otherwise specified, similar reference numbers refer to the same elements throughout the drawings.

[0009] [Figure 1] This figure shows an example of a vehicle portion in which embodiments, features, and elements disclosed herein may be implemented.

[0010] [Figure 2]This figure shows an example of a part of a vehicle transport and communication system in which embodiments, features, and elements disclosed herein may be implemented.

[0011] [Figure 3] This diagram shows a system for vehicle control using edging and virtual stop line generation, implemented according to the present disclosure.

[0012] [Figure 4] This is a flowchart illustrating the method for edging and virtual stop line generation as implemented in this disclosure.

[0013] [Figure 5] Figures 5A and 5B illustrate an example of determining the visible space of a host vehicle according to an implementation of this disclosure.

[0014] [Figure 6A] This is a diagram illustrating an example of identifying the location of a virtual road user.

[0015] [Figure 6B] This is a diagram illustrating an example of determining the most relevant virtual road user in accordance with the implementation of this disclosure.

[0016] [Figure 7] Figures 7A and 7B illustrate an example of generating a virtual stop line according to an implementation of the present disclosure.

[0017] [Figure 8] This is a diagram illustrating an example of determining a target speed limit in accordance with the implementation of this disclosure.

[0018] [Figure 9] This is a diagram of another system for vehicle control using edging and virtual stop line generation, as implemented in this disclosure. [Modes for carrying out the invention]

[0019] A vehicle may travel through a portion of a vehicle traffic network. The vehicle traffic network may include one or more impassable zones such as buildings, one or more partially passable zones such as parking zones (e.g., parking lots, parking spaces, etc.), one or more passable zones such as roads (including lanes, median strips, intersections, etc.), or a combination thereof.

[0020] A vehicle may include one or more sensors. Traveling through the vehicle traffic network may include the sensors generating or capturing sensor data, such as data corresponding to the operating environment of the vehicle or a portion thereof. For example, the sensor data may include information corresponding to one or more potential hazards that are embodied as respective external objects, or (e.g., identified as being respective external objects). Such objects may also be referred to herein as hazard objects.

[0021] The hazard object may be a static object. A static object is an object that is stationary and is not expected to move in the next few seconds. Examples of static objects include bicycles with no rider, inoperative vehicles, vehicles with no occupants, road signs, walls, buildings, depressions, and the like.

[0022] The hazard object may be a stationary object. A stationary object is an object that is stationary but may move at any time. Examples of stationary objects include vehicles stopped at traffic lights, and vehicles that are on the roadside with an occupant (e.g., a driver). In some implementations, stationary objects may be considered as static objects.

[0023] The hazard object may be a dynamic (i.e., moving) object such as a pedestrian, a remote vehicle, a motorcycle, a bicycle, or the like. The dynamic object may be oncoming (may be heading toward the vehicle) or may be moving in the same direction as the vehicle. The dynamic object may be moving longitudinally or laterally relative to the vehicle. A stationary object may become a dynamic object, and vice versa.

[0024] There are two common response approaches to detecting a potential hazard. The vehicle may ignore the potential hazard until it is confirmed that the hazard is a hazardous object that could obstruct the vehicle's path, or until it is confirmed to be a false positive (e.g., the potential hazard was a sensor error). Alternatively, the vehicle may treat all potential hazards as hazardous objects that could obstruct the vehicle's path. Neither approach is desirable in all cases. Waiting may result in the inability to avoid the hazard, or in unnatural or uncomfortable maneuvers for any passenger in the vehicle to avoid the hazard. Treating a potential hazard as a hazardous object may result in the vehicle making unnecessary maneuvers (such as slowing down or lateral movement) when the potential hazard does not materialize.

[0025] Alternatively, as taught herein, proactive risk mitigation may be used when planning a proactive trajectory for a vehicle that minimizes changes in velocity and / or lateral movement in response to a potential hazard, while still allowing for a comfortable and safe response (i.e., a response trajectory) in events where a hazard obstructs the vehicle's path, by taking into account the vehicle's responsiveness.

[0026] This solution may leverage the fact that even when the driving environment is dynamic, it is possible to predict / anticipate the vehicle's response to road conditions (i.e., a person-driven vehicle, a remotely controlled vehicle, etc.). The behavior of hazardous objects can similarly be predicted, as the flow of traffic in a vehicle network is governed by road traffic laws (e.g., vehicles turning left yield to oncoming traffic, vehicles travel between lane markings), social customs (e.g., drivers yield to the driver on the right at a stop sign), and physical constraints (e.g., a stationary object does not instantaneously move laterally within the vehicle's path).

[0027] This predictability may be used to predict the behavior of hazards in order to control the response of vehicles, such as autonomous vehicles, semi-autonomous vehicles, or any other vehicles including advanced driver-assistance systems (ADAS), while they are traveling through a traffic network. For example, if a vehicle is traveling in its lane on a two-lane road and is approaching an intersection, it is likely that other vehicles are also approaching the same intersection at the same time. Therefore, the vehicle may approach the intersection at a lower speed so as to confirm that there is no hazard before proceeding. In this case, a predictive trajectory may be determined for the vehicle, which adjusts the planned route and speed in advance to avoid a collision if the hazard materializes as predicted.

[0028] However, when the hazardous object is a moving object, the predicted behavior based on expected constraints may not accurately capture the entire range of possible behaviors. The moving object may not yield or may deviate from its expected path. The moving object may increase or decrease its speed, either on its own or in combination with other unlikely behaviors (e.g., not yielding or deviating). In such cases, the interaction between the vehicle and the moving object may occur at an uncertain time and location. The predictive trajectories described herein address this unpredictability.

[0029] Furthermore, if multiple hazards are identified, each hazard may be considered separately, regardless of whether or not they involve moving objects. However, considering each hazard separately may not result in an optimal trajectory, because different hazards may represent different levels of risk to the vehicle. It is desirable to define a predictive trajectory by considering all hazards, especially when a vehicle is traveling along a narrow lane or residential street, where multiple hazards on both sides of the vehicle can create a cluttered driving environment.

[0030] In addition to actual (e.g., perceived or observed) hazards as described above, this disclosure also relates to (e.g., applies to) hypothetical hazards. Human drivers, in addition to reacting to observed objects (e.g., adjusting their driving behavior in response to observed objects), also tend to drive slower and take other precautions when turning sharp corners and / or driving in environments with limited visibility (e.g., on foggy days or when lanes are not fully visible), or when anticipating the unexpected appearance of vehicles. Human drivers will anticipate the possibility of another road user (e.g., a vehicle) appearing just beyond their perceptual limits and will take proactive actions in preparation for such events. For example, a human driver may slow down or move closer depending on their field of vision. To mimic the behavior of human drivers and thereby provide comfort to vehicle occupants, the proactive risk mitigation described herein may also apply to hypothetical hazards (or hypothetical vehicles).

[0031] A virtual vehicle is an embodied vehicle added to the world model. At the time a virtual vehicle is added to the world model, it does not correspond to an actual vehicle perceived by the vehicle's sensors. Processing of virtual vehicles may proceed, at least to a considerable extent, as if it were an actually perceived vehicle. That is, predictive risk mitigation may plan trajectories based on (e.g., taking virtual vehicles into consideration) the virtual vehicle. Predictive risk mitigation using a generalized virtual vehicle generates (e.g., embodies) the virtual vehicle within the occluding area of ​​the road (e.g., the lanes on it) or within the maximum perceptual range. The virtual vehicle may then be used as a hazard so that constraints can be generated within the framework described herein, e.g., predictive risk mitigation and trajectory planning. As described herein, such constraints may be or include the pre-allocation of space for speed reduction and / or overtaking. Note that unless specifically stated otherwise or evident from the context, references to “hazards” include both actual and virtual hazards.

[0032] To illustrate in more detail some implementations of predictive risk mitigation through the teachings of this specification, we first refer to the environments in which this disclosure may be implemented.

[0033] Figure 1 is a diagram illustrating an example of a portion of a vehicle 100 in which embodiments, features, and elements disclosed herein may be implemented. The vehicle 100 includes a chassis 102, a powertrain 104, a controller 114, and wheels 132 / 134 / 136 / 138, and may further include any other elements or combinations of elements of the vehicle. For simplicity, the vehicle 100 is shown to include four wheels 132 / 134 / 136 / 138, but any other propulsion device such as a propeller or tracks may be used. In Figure 1, the lines interconnecting elements such as the powertrain 104, the controller 114, and the wheels 132 / 134 / 136 / 138 indicate that information such as data or control signals, power such as electricity or torque, or both information and power may be transmitted between the respective elements. For example, the controller 114 may receive power from the powertrain 104 and communicate with the powertrain 104, the wheels 132 / 134 / 136 / 138, or both, to control the vehicle 100, which may include accelerating, decelerating, steering, or otherwise controlling the vehicle 100.

[0034] The powertrain 104 includes a power source 106, a transmission 108, a steering unit 110, and a vehicle actuator 112, and may further include any other elements or combinations of elements of the powertrain, such as a suspension, drive shafts, axles, or exhaust system. Wheels 132 / 134 / 136 / 138, as shown separately, may also be included in the powertrain 104.

[0035] The power source 106 may be any device or combination of devices capable of supplying energy such as electrical energy, thermal energy, or kinetic energy. For example, the power source 106 may include an engine such as an internal combustion engine, an electric motor, or a combination of an internal combustion engine and an electric motor, and may be operated to supply kinetic energy as propulsion to one or more wheels 132 / 134 / 136 / 138. In some embodiments, the power source 106 may include a potential energy unit such as one or more dry cell batteries, solar cells, fuel cells, or any other device capable of supplying energy, such as nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), or lithium-ion (Li-ion).

[0036] The transmission 108 receives energy such as kinetic energy from the power source 106 and transmits that energy to the wheels 132 / 134 / 136 / 138 to provide propulsion. The transmission 108 may be controlled by the controller 114, the vehicle actuator 112, or both. The steering unit 110 may be controlled by the controller 114, the vehicle actuator 112, or both, and steers the vehicle by controlling the wheels 132 / 134 / 136 / 138. The vehicle actuator 112 may receive signals from the controller 114 and actuate or control the power source 106, the transmission 108, the steering unit 110, or any combination thereof to operate the vehicle 100.

[0037] In the illustrated embodiment, the controller 114 includes a position unit 116, an electronic communication unit 118, a processor 120, a memory 122, a user interface 124, a sensor 126, and an electronic communication interface 128. Although shown as a single unit, one or more elements of the controller 114 may be integrated into any number of separate physical units. For example, the user interface 124 and the processor 120 may be integrated into a first physical unit, and the memory 122 may be integrated into a second physical unit. Although not shown in Figure 1, the controller 114 may include a power source such as a battery. Although shown as separate elements, the position unit 116, the electronic communication unit 118, the processor 120, the memory 122, the user interface 124, the sensor 126, the electronic communication interface 128, or any combination thereof, may be integrated into one or more electronic units, circuits, or chips.

[0038] In some embodiments, the processor 120 includes any existing or future-developed device or combination of devices capable of manipulating or processing signals or other information, such as an optical processor, a quantum processor, a molecular processor, or a combination thereof. For example, the processor 120 may include one or more dedicated processors, one or more digital signal processors, one or more microprocessors, one or more controllers, one or more microcontrollers, one or more integrated circuits, one or more application-specific integrated circuits, one or more field-programmable gate arrays, one or more programmable logic arrays, one or more programmable logic controllers, one or more state machines, or any combination thereof. The processor 120 may be operably coupled to a position unit 116, a memory 122, an electronic communication interface 128, an electronic communication unit 118, a user interface 124, a sensor 126, a powertrain 104, or any combination thereof. For example, the processor may be operably coupled to the memory 122 via a communication bus 130.

[0039] The processor 120 may be configured to execute instructions. Such instructions may include instructions for remote operation, which may be used to operate the vehicle 100 from a remote location, including an operation center. Instructions for remote operation may be stored within the vehicle 100 or received from an external source, such as a traffic management center or a server computing device, the server computing device may include a cloud-based server computing device. The processor 120 may also implement some or all of the foreseeable risk mitigation described herein.

[0040] Memory 122 may include, for example, any tangible non-temporary computer-usable or computer-readable medium capable of containing, storing, communicating, or transporting machine-readable instructions or any related information for use by or in connection with the processor 120. Memory 122 may include, for example, one or more solid-state drives, one or more memory cards, one or more removable media, one or more read-only memories (ROMs), one or more random-access memories (RAMs), one or more registers, one or more low-power double data-rate (LPDDR) memories, one or more cache memories, one or more disks (including hard disks, floppy disks, or optical disks), magnetic cards or optical cards, or any type of non-temporary medium suitable for storing electronic information, or any combination thereof.

[0041] The electronic communication interface 128 may be a wireless antenna, a wired communication port, an optical communication port, or any other wired or wireless unit capable of interfacering with a wired or wireless electronic communication medium 140, as shown in the figure.

[0042] The electronic communication unit 118 may be configured to transmit or receive signals via a wired or wireless electronic communication medium 140, such as via an electronic communication interface 128. Although not explicitly shown in Figure 1, the electronic communication unit 118 may be configured to transmit, receive, or both, via any wired or wireless communication medium, such as radio frequency (RF), ultraviolet (UV), visible light, optical fiber, wired line, or a combination thereof. Figure 1 shows one electronic communication unit 118 and one electronic communication interface 128, but any number of communication units and any number of communication interfaces may be used. In some embodiments, the electronic communication unit 118 may include a dedicated narrow-range communication (DSRC) unit, a wireless safety unit (WSU), IEEE 802.11p (WiFi-P), or a combination thereof.

[0043] The positioning unit 116 may determine the position information of the vehicle 100, including but not limited to longitude, latitude, altitude, direction of travel, or speed. For example, the positioning unit includes a Global Positioning System (GPS) unit such as a Wide Area Augmentation System (WAAS) Compatible National Marine Electronics Association (NMEA) unit, a radio triangulation unit, or a combination thereof. The positioning unit 116 may be used, for example, to obtain information representing the current bearing of the vehicle 100, the current position of the vehicle 100 in two or three dimensions, the current angular direction of the vehicle 100, or a combination thereof.

[0044] The user interface 124 may include any unit that can be used as an interface by a person, including a virtual keypad, a physical keypad, a touchpad, a display, a touchscreen, a speaker, a microphone, a video camera, a sensor, and a printer. The user interface 124 may be operably coupled to the processor 120 as shown, or to any other element of the controller 114. Although shown as a single unit, the user interface 124 may include one or more physical units. For example, the user interface 124 may include an audio interface for voice communication with a person and a touch display for visual and touch-based communication with a person.

[0045] Sensor 126 may include one or more sensors, such as a sensor array, that are operable to provide information that can be used to control the vehicle. Sensor 126 may provide information about the current operating characteristics of the vehicle or its surroundings. Sensor 126 may include, for example, a speed sensor, an acceleration sensor, a steering angle sensor, a traction-related sensor, a braking-related sensor, or any sensor or combination of sensors that are operable to report information about any aspect of the current dynamic condition of the vehicle 100.

[0046] In some embodiments, the sensor 126 includes sensors that can operate to acquire information about the physical environment surrounding the vehicle 100. For example, one or more sensors may detect road shape and obstacles, such as fixed obstacles, vehicles, cyclists, and pedestrians. The sensor 126 may be, or include, one or more video cameras, laser sensing systems, infrared sensing systems, acoustic sensing systems, or any other suitable type of in-vehicle environment sensing device, or a combination of currently known or later developed devices. The sensor 126 and the position unit 116 may be combined.

[0047] Although not shown separately, the vehicle 100 may include a track controller. For example, controller 114 may include a track controller. The track controller may be operable to acquire information describing the current state of the vehicle 100 and a planned path for the vehicle 100, and may determine and optimize a track for the vehicle 100 based on this information. In some embodiments, the track controller outputs a signal operable to control the vehicle 100 so that it follows a track determined by the track controller. For example, the output of the track controller may be an optimized track which may be supplied to the powertrain 104, wheels 132 / 134 / 136 / 138, or both. The optimized track may be a control input such as a set of steering angles, where each steering angle corresponds to a time or position. The optimized track may be one or more paths, lines, curves, or a combination thereof.

[0048] One or more of the wheels 132 / 134 / 136 / 138 may be steering wheels that are turned to a steering angle under the control of the steering unit 110, drive wheels that are supplied with torque to propel the vehicle 100 under the control of the transmission 108, or steering and driving wheels that steer and propel the vehicle 100.

[0049] The vehicle may include units or elements not shown in Figure 1, such as a housing, a Bluetooth® module, a frequency modulation (FM) radio unit, a near-field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a speaker, or any combination thereof.

[0050] The vehicle, for example, vehicle 100, may be an autonomous vehicle or a semi-autonomous vehicle. For example, the term autonomous vehicle as used herein should be understood to include a vehicle that includes an advanced driver-assistance system (ADAS). ADAS can automate, adapt, and / or enhance vehicle systems for safety and better driving by avoiding or otherwise correcting driver errors.

[0051] Figure 2 is a diagram illustrating an example of a portion of a vehicle transport and communication system 200 in which embodiments, features, and elements disclosed herein may be implemented. The vehicle transport and communication system 200 includes a vehicle 202, such as the vehicle 100 shown in Figure 1, and one or more external objects, such as an external object 206, which may include any form of transport, such as the vehicle 100 shown in Figure 1, pedestrians, cyclists, and any form of structure, such as a building. The vehicle 202 may travel through one or more portions of the traffic network 208 and may communicate with the external object 206 via one or more electronic communication networks 212. Although not explicitly shown in Figure 2, the vehicle may travel through areas not explicitly or entirely included in the traffic network, such as off-road areas. In some embodiments, the traffic network 208 may include one or more vehicle detection sensors 210, such as guidance loop sensors, which may be used to detect the movement of vehicles on the traffic network 208.

[0052] The electronic communication network 212 may be a multiple access system that provides communication such as voice communication, data communication, video communication, message communication, or a combination thereof between the vehicle 202, the external object 206, and the operation center 230. For example, the vehicle 202 or the external object 206 may receive information such as information representing the traffic network 208 from the operation center 230 via the electronic communication network 212.

[0053] The operation center 230 includes a controller device 232, which includes some or all of the features of the controller 114 shown in Figure 1. The controller device 232 may monitor and coordinate the movement of vehicles, including autonomous vehicles. The controller device 232 may monitor the state or condition of vehicles such as vehicle 202 and external objects such as external objects 206. The controller device 232 can receive vehicle data and infrastructure data, which may include any of the following: vehicle speed, vehicle position, vehicle operating status, vehicle destination, vehicle route, vehicle sensor data, external object speed, external object position, external object operating status, external object destination, external object route, and external object sensor data.

[0054] Furthermore, the controller device 232 may establish remote control of one or more vehicles, such as vehicle 202, or external objects, such as external object 206. In this way, the controller device 232 may remotely operate the vehicles or external objects from a remote location. The controller device 232 may exchange (transmit or receive) status data with the vehicles, external objects, or computing devices, such as vehicle 202, external object 206, or server computing device 234, via wireless communication links, such as wireless communication link 226, or wired communication links, such as wired communication link 228.

[0055] The server computing device 234 may include one or more server computing devices and may exchange (transmit or receive) status signal data with one or more vehicles or computing devices, including the vehicle 202, external object 206, or operation center 230, via the electronic communication network 212.

[0056] In some embodiments, the vehicle 202 or external object 206 communicates via a wired communication link 228, wireless communication links 214 / 216 / 224, or any combination of any number or types of wired or wireless communication links. For example, as shown, the vehicle 202 or external object 206 communicates via a terrestrial wireless communication link 214, via a non-terrestrial wireless communication link 216, or a combination thereof. In some implementations, the terrestrial wireless communication link 214 includes an Ethernet link, a serial link, a Bluetooth link, an infrared (IR) link, an ultraviolet (UV) link, or any link capable of electronic communication.

[0057] A vehicle, for example, vehicle 202, or an external object, for example, external object 206, may communicate with another vehicle, external object, or operation center 230. For example, a host vehicle or target vehicle 202 may receive one or more vehicle-to-vehicle messages, such as basic safety messages (BSMs), from operation center 230 via direct communication link 224 or via electronic communication network 212. For example, operation center 230 may broadcast messages to host vehicles within a defined broadcast range, such as 300 meters, or to a defined geographic area. In some embodiments, vehicle 202 receives messages via a third party, such as a signal relay (not shown) or another remote vehicle. In some embodiments, vehicle 202 or external object 206 periodically transmits one or more vehicle-to-vehicle messages based on a defined interval, such as 100 milliseconds.

[0058] Vehicle 202 may communicate with the electronic communications network 212 via access point 218. Access point 218 may include a computing device and is configured to communicate with vehicle 202, the electronic communications network 212, the operation center 230, or a combination thereof, via wired or wireless links 214 / 220. For example, access point 218 is a base station, base transceiver station (BTS), Node-B, enhancedNode-B (eNode-B), HomeNode-B (HNode-B), wireless router, wired router, hub, relay, switch, or any other similar wired or wireless device. Although shown as a single unit, access point may include any number of interconnected elements.

[0059] Vehicle 202 may communicate with the electronic communications network 212 via satellite 222 or other non-terrestrial communications devices. Satellite 222 may include computing devices and may be configured to communicate with vehicle 202, the electronic communications network 212, the operations center 230, or a combination thereof, via one or more communications links 216 / 236. Although shown as a single unit, the satellite may include any number of interconnected elements.

[0060] The electronic communication network 212 may be any type of network configured to provide voice, data, or any other type of electronic communication. For example, the electronic communication network 212 may include a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), a mobile or cellular telephone network, the Internet, or any other electronic communication system. The electronic communication network 212 may use communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), Real-time Transport Protocol (RTP), Hypertext Transport Protocol (HTTP), or a combination thereof. Although shown as a single unit, the electronic communication network may include any number of interconnected elements.

[0061] In some embodiments, the vehicle 202 communicates with the operation center 230 via an electronic communication network 212, an access point 218, or a satellite 222. The operation center 230 may include one or more computing devices that can exchange (transmit or receive) data from vehicles such as the vehicle 202, data from external objects including external objects 206, or data from computing devices such as a server computing device 234.

[0062] In some embodiments, the vehicle 202 identifies a portion or state of the traffic network 208. For example, the vehicle 202 may include one or more on-board sensors 204, such as the sensor 126 shown in Figure 1, which may include speed sensors, wheel speed sensors, cameras, gyroscopes, optical sensors, laser sensors, radar sensors, acoustic sensors, or any other sensors or devices or combinations thereof capable of determining or identifying a portion or state of the traffic network 208.

[0063] Vehicle 202 may travel through one or more parts of the traffic network 208 using information communicated via the electronic communication network 212, such as information representing the traffic network 208, information identified by one or more onboard sensors 204, or a combination thereof. External objects 206 may be capable of performing all or part of the above-described communications and operations with respect to vehicle 202.

[0064] For simplicity, Figure 2 shows a vehicle 202 as a host vehicle, external objects 206, a transportation network 208, an electronic communication network 212, and an operation center 230. However, any number of vehicles, networks, or computing devices may be used. In some embodiments, the vehicle transport and communication system 200 includes devices, units, or elements not shown in Figure 2.

[0065] Although the vehicle 202 is shown communicating with the operation center 230 via the electronic communication network 212, the vehicle 202 (and external objects 206) may communicate with the operation center 230 via any number of direct or indirect communication links. For example, the vehicle 202 or external object 206 may communicate with the operation center 230 via a direct communication link such as a Bluetooth communication link. For simplicity, Figure 2 shows one of the traffic networks 208 and one of the electronic communication networks 212, but any number of networks or communication devices may be used.

[0066] The external object 206 is illustrated as a second remote vehicle in Figure 2. The external object is not limited to another vehicle. The external object may be any infrastructure element capable of transmitting data to the operation center 230, such as a fence, sign, building, etc. The data may be, for example, sensor data from the infrastructure element.

[0067] Figure 3 is a diagram of a system 300 for vehicle control using edging and virtual stop line generation, as implemented in this disclosure. While the description concerns a vehicle traffic network, e.g., a vehicle traveling through a vehicle traffic network 208, the teachings herein may be used in any area on which a vehicle can travel, and these areas are collectively referred to as a vehicle traffic network. System 300 may represent a software pipeline for a vehicle, such as vehicle 100 in Figure 1. System 300 includes a world model 302, a route planner 304, a decision module 306, a predictive trajectory planner 308, and a reaction trajectory control 310. Other examples of system 300 may include more, fewer, or other components. In some examples, the components may be combined, and in other examples, the components may be divided into multiple components. System 300 does not need to be implemented in a vehicle; instead, system 300 may be implemented entirely or partially by a remote assistance control system, such as a remote assistance control system operating on a server computing device 234.

[0068] World Model 302 receives sensor data, such as that from Sensor 126 in Figure 1, and determines objects from the sensor data (e.g., transform, detect, etc.). That is, World Model 302 determines hazardous objects (e.g., road users) from the received sensor data. For example, World Model 302 can transform a point cloud received from a light detection and ranging (LiDAR) sensor (i.e., a sensor within Sensor 126) into an object such as a hazardous object. Sensor data from multiple sensors may be fused to identify an object. Examples of objects include non-powered vehicles (e.g., bicycles), pedestrians or animals, powered vehicles, etc.

[0069] The world model 302 may receive sensor information that enables the world model 302 to calculate and maintain additional information for at least some detected objects. For example, the world model 302 may maintain a state for at least some determined objects. The state of an object may include zero or more of the following: velocity, orientation, geometry (width, height, and depth, etc.), classification (e.g., bicycle, large truck, pedestrian, road sign, etc.), and position. Thus, the state of an object includes discrete state information (e.g., classification) and continuous state information (e.g., orientation and velocity).

[0070] World Model 302 fuses sensor information, tracks objects, maintains a list of hypotheses for at least some dynamic objects (e.g., object A may go straight, turn right, or turn left), generates and maintains a predicted trajectory for each hypothesis, and maintains a likelihood estimate for each hypothesis (e.g., object A is going straight with a 90% probability, considering the object's attitude / velocity and the trajectory's attitude / velocity). In one example, World Model 302 may use an instance of the trajectory planner to generate a predicted trajectory for each object hypothesis for at least some dynamic objects. For example, an instance of the trajectory planner may be used to generate predicted trajectories for vehicles, bicycles, and pedestrians. In another example, an instance of the trajectory planner, such as the trajectory planner described below, may be used to generate predicted trajectories for vehicles and bicycles, and a different method may be used to generate a predicted trajectory for pedestrians.

[0071] Objects maintained under World Model 302 may include hazardous objects, which may include static objects, dynamic objects, or both.

[0072] The route planner 304 determines the road-level plan. For example, given a starting point and a destination point, the route planner 304 determines the route from the starting point to the destination point. The route planner 304 may also determine a list of roads (i.e., a road-level plan) that a vehicle should follow to travel from the starting point to the destination point.

[0073] The road level plan determined by the route planner 304, as well as the objects (and corresponding state information) maintained by the world model 302, may be used by the decision module 306 to determine discrete level decisions in line with the road level plan. Examples of decisions included in discrete level decisions include stopping at the next intersection, moving forward slowly, accelerating to a certain speed limit, and merging into the next lane.

[0074] The predictive trajectory planner 308 may receive discrete level determinations, objects (and corresponding state information) maintained by the world model 302, and predicted trajectories and likelihoods of external objects from the world model 302. The predictive trajectory planner 308 may use at least a portion of the received information to determine a detailed planned trajectory for the vehicle, which is also referred to herein as the predictive trajectory.

[0075] For example, the predictive trajectory planner 308 determines the trajectory for the next few seconds. Therefore, in an example where the next few seconds is the next 6 seconds (i.e., the look-ahead time is 6 seconds), the predictive trajectory planner 308 determines the vehicle's trajectory and position for the next 6 seconds. For example, the predictive trajectory planner 308 may also determine the expected position of the vehicle at several time intervals (e.g., every quarter second, or at other time intervals) (e.g., by prediction or calculation). The predictive trajectory planner 308 is described in more detail below.

[0076] The reactive trajectory control 310 can handle situations that a vehicle may encounter but that the predictive trajectory planner 308 may not address. Such situations include situations where the predictive trajectory of the predictive trajectory planner 308 is based on misclassification of an object and / or an unexpected situation that rarely occurs. For example, the reactive trajectory control 310 may correct the predictive trajectory in response to determining that a static object to the left of the vehicle is misclassified. That object may have been classified as a large truck, but the new classification may determine that it is a static road barrier wall. In another example, the reactive trajectory control 310 may correct the predictive trajectory in response to a sudden tire burst of the vehicle. Other examples of unexpected situations include another vehicle suddenly deviating into the vehicle's lane (e.g., due to a delayed decision to head towards a highway exit ramp or a tire burst), and a pedestrian or other object suddenly appearing from behind a shield.

[0077] In some implementations, the prediction algorithm of the predictive trajectory planner 308 may be configured to generate plans at 10 Hz. On the other hand, the reaction trajectory control 310 may be configured to generate plans at 100 Hz.

[0078] Figure 4 is a flowchart of a method or process 400 for edging and virtual stop line generation, as implemented according to the teachings of this specification. Process 400 includes operations 402 to 422, which are described below. Process 400 may be implemented entirely or partially by the system 300 of Figure 3, in particular the predictive trajectory planner 308. Process 400 may be stored in memory (e.g., memory 122 in Figure 1) as instructions that can be executed by the processor (e.g., processor 120 in Figure 1) of a host vehicle (e.g., vehicle 100 in Figure 1). Process 400 may be implemented entirely or partially by a remote support control system, such as a server computing device 234.

[0079] Process 400 receives an input, which may include sensor data (i.e., sensor observations), such as measurements from one or more sensors 126. The sensor data may be used to detect real-world objects. For example, the sensor data may be used to determine if a real-world object is within the host vehicle's field of view.

[0080] In one example, data from one or more cameras may be used to determine the class of a detected object. Examples of non-limiting classes include "automobile," "sports car," "sedan," "large truck," "pedestrian," and "bicycle." In another example, the classification may be assigned based on light detection and ranging (LiDAR) data, for example, the movement of a LiDAR point cloud over time. Note that different sensor data may provide different object classifications. For example, a first classification of "bicycle" may be determined based on LiDAR data, while a second classification of "jogger" may be determined based on camera data. Therefore, the classification of an object may be determined probabilistically (e.g., which of the first and second classifications is more likely). Because the classification is probabilistic, the classification of an object may change over time. Different sensor data may be fused together to determine the classification.

[0081] In one implementation, process 400 may receive map information as input. The map information may include map lane structures (also referred to herein as road structures or mapped lanes). The map lane structure of a given lane may include information on following lanes, preceding lanes, and sibling lanes.

[0082] In operation 402, process 400 generates at least one virtual road user. The virtual road user may be a virtual vehicle or a virtual hazard as described above. The position of at least one virtual vehicle depends on the range of the host vehicle's sensors. The host vehicle may be vehicle 202 in Figure 2. That is, at least one virtual vehicle may be placed at the edge of the host vehicle's sensor range. For example, as the host vehicle approaches an intersection, the range of the host vehicle's sensors is limited by various factors such as other road users or other real-world objects (e.g., buildings, bus stops, benches, etc.). The sensor range can vary from narrow (e.g., the width of the host vehicle) to wide (e.g., as wide as the width the sensor range allows). If the sensor range is narrow (i.e., below the minimum distance threshold), the virtual road user is generated at the edge of the sensor range. If the sensor range is wide (i.e., above the minimum distance threshold), the virtual road user does not have to be placed at the edge of the sensor range (it may be omitted).

[0083] In operation 404, process 400 determines the most relevant virtual road user, also known as the most relevant road user. The most relevant virtual road user is a virtual road user from at least one other virtual user, and may be associated with the lane that the host vehicle crosses earliest. In other words, the most relevant virtual road user may be a virtual road user associated with the lane that the host vehicle crosses earliest, relative to the virtual road users associated with that lane. For example, as the host vehicle approaches an intersection, the intersection may have multiple lanes. Depending on the host vehicle's planned trajectory (i.e., route), road traffic regulations, and the range of sensors in different directions, the host vehicle may cross one lane earlier than another. The virtual road user associated with the earliest lane that the host vehicle may cross may be the most relevant virtual road user, and is considered the virtual road user that interacts with the host vehicle earliest.

[0084] In operation 406, process 400 determines the time to contact with the most relevant virtual road user. The time to contact with the most relevant road user represents the amount of time the host vehicle may have before colliding with the most relevant road user. The time to contact may be determined using the acceleration of the host vehicle, the predicted trajectory of the most relevant road user, and the relative distance between the host vehicle and the most relevant virtual road user. That is, the time to contact may be determined by predicting the point where the two intersect using the acceleration of the host vehicle and the predicted trajectory of the most relevant virtual road user. Then, based on the acceleration of the host vehicle, the predicted trajectory of the most relevant road user, and the distance between the host vehicle and the most relevant virtual road user, process 400 determines the amount of time that may have elapsed before the host vehicle reaches the intersection.

[0085] In operation 408, process 400 generates a virtual stop line for the host vehicle. The virtual stop line represents the furthest point in the lane the host vehicle is currently traveling in that it can travel to before entering the intersection. In other words, the host vehicle may be required to stop before entering the intersection, and the virtual stop line represents the point where the host vehicle can stop. The virtual stop line may be created offset (longitudinally) from the intersection with the most relevant road users. The offset distance may depend on the road's speed limit and whether the host vehicle is crossing the intersection or merging into one of the lanes. For example, an ideal offset might be 6 meters (m) when the host vehicle is crossing an intersection on a road with a speed limit of 25 miles per hour (mph) or less. Continuing this example, if the road's speed limit exceeds 25 miles per hour, the offset may increase to 6.5 m. Alternatively, if the host vehicle is merging into a lane of an intersecting road and the speed limit is 25 miles per hour or less, an ideal offset might be 4.5 m. Finally, if the speed limit increases beyond 25 mph, the ideal offset increases to 5.5m for the merging host vehicle.

[0086] Ideal offset values ​​are given for various scenarios, but these are not the only values ​​that can be used. Other values, or a wider range or classification of values, may be used as appropriate. In general, the offset may increase with the road speed limit, and may be greater when crossing an intersection than when merging into a lane (for example, at the same speed).

[0087] In operation 410, process 400 determines whether the vehicle needs to stop at the virtual stop line. The determination may be based on the host vehicle's acceleration, the time to contact, or any combination thereof. The minimum acceleration and minimum contact time may depend on the speed limit of the road the host vehicle is crossing or merging onto. The minimum acceleration ensures that the host vehicle passes through the intersection quickly enough, while the minimum contact time ensures that the host vehicle has enough time to cross the intersection if an actual road user were present at the virtual road user's position. If the vehicle's acceleration is less than the minimum acceleration, or if the time to contact is less than the minimum contact time, process 400 may determine that the host vehicle should stop at the virtual stop line. For example, if the road's speed limit is 25 miles per hour, the minimum acceleration is -1 meters per second squared (m / s²). 2 ) may be, and the minimum contact time may be 1 second (s). On the other hand, if the road speed limit is 45 miles per hour, the minimum acceleration is -0.5 m / s². 2 This may also be the case, and the minimum contact time may be 3.5s.

[0088] If the host vehicle's acceleration is less than the minimum acceleration, or if the time to contact is less than the minimum contact time, process 400 proceeds to operation 412. However, if the host vehicle's acceleration is greater than or equal to the minimum acceleration, and the time to contact is greater than or equal to the minimum contact time, process 400 proceeds to operation 414.

[0089] In operation 412, process 400 sets a target speed such that the host vehicle stops at the virtual stop line. That is, the host vehicle may not be able to safely pass through the intersection if its acceleration is less than the minimum acceleration, or if the time to contact is less than the minimum contact time. Therefore, process 400 may set the target speed of the vehicle so that it stops at the virtual stop line instead of attempting to cross the intersecting road or merge into the lane of the intersecting road. For example, if the acceleration is 0.1 m / s². 2 If the time to contact is 3 seconds and the speed limit is 45 miles per hour, process 400 may use the above minimum acceleration and minimum contact time to determine that the host vehicle cannot safely pass through the intersection and therefore set the target speed to stop at the virtual stop line. Alternatively, if the speed limit is instead 25 miles per hour and all other factors remain the same, process 400 may determine that the host vehicle can safely pass through the intersection. Therefore, process 400 does not set the target speed to stop at the virtual stop line. Instead, process 400 proceeds to action 414.

[0090] In operation 414, process 400 determines the target speed of the host vehicle. The target speed may be determined based on the relative distance to the most relevant virtual road user and the time to contact. More specifically, the target speed may be based on the minimum of two equations that use the relative distance to the most relevant virtual road user and the time to contact. The equation using relative distance may be expressed as equation (1). (relDist - 30) * 1.5 / 50

[0091] In equation (1), the variable relDist is the relative distance between the host vehicle and (for example, the trajectory of the most relevant virtual road user).

[0092] The formula using the time to contact (TTC) may also be expressed by formula (2). (TTC - 3) * 1.5 / 5

[0093] For example, if the most relevant virtual road user is close to the host vehicle, or if the time to contact is short (for example, if the most relevant virtual road user is moving rapidly), the host vehicle may travel at a slower speed to ensure safe visibility before proceeding through the intersection.

[0094] In operation 416, process 400 receives a strategic speed plan. The strategic speed plan may be received from the route planner 304 in Figure 3. The strategic speed plan may be specific speeds along different portions of the host vehicle's planned trajectory. The strategic speed plan represents the ideal speeds at which the host vehicle may travel as it travels through the vehicle traffic network 208. Although described as a separate operation, the strategic speed plan may be transmitted periodically and may be received before process 400 begins, and may also be updated during process 400.

[0095] In operation 418, process 400 evaluates the sensor range (also called the sensor range) and the distance to the virtual road user(s). If the sensor range exceeds the minimum distance, or if the distance to the nearest virtual road user(s) exceeds the minimum distance, process 400 proceeds to operation 420; otherwise, process 400 proceeds to operation 422. In other words, if the host vehicle's sensor range (e.g., line of sight) is no longer limited by other real-world objects, or if the virtual road users generated at the edge of the host vehicle's sensor range are far enough away that the vehicle can safely pass through the intersection, the process proceeds to operation 420.

[0096] In operation 420, process 400 increases the target to match the strategic speed plan. That is, the target speed may be set to match the strategic speed plan with respect to the corresponding position of the host vehicle along the planned trajectory.

[0097] In operation 422, process 400 operates the host vehicle using a target speed plan. In other words, the target speed plan may be transmitted to the host vehicle's control system. The control system may be the controller 114 in Figure 1 or the vehicle 100. The control system may then set the host vehicle's speed to match the target speed as the host vehicle passes through the intersection. In implementations where a remote vehicle assistance system is used, process 400 may operate the host vehicle directly.

[0098] Figures 5A and 5B illustrate an example of determining the visible space of a host vehicle, which may be used when generating at least one virtual road user in operation 404. Figure 500 in Figure 5A is an example of the visible space (i.e., sensor range) of the host vehicle. Figure 500 shows vehicle 202 (i.e., the host vehicle), intersection 502, real-world objects 504 (e.g., buildings, parked vehicles, other road users, trees, etc.), and the visible space 506 of the host vehicle. As illustrated, the visible space 506 of vehicle 202 may be limited due to the positional relationship of vehicle 202 to intersection 502 and real-world objects that obstruct the sensor range of vehicle 202. Thus, the visible space 506 is limited to a trapezoidal shape with the narrow side facing forward of vehicle 202 and the wide side facing away from intersection 502 as seen from vehicle 202. In other words, the further vehicle 202 is from intersection 502, the smaller or more limited the visible space 506 may be.

[0099] Diagram 510 in Figure 5B is another example of the visible space of a host vehicle. Diagram 510 shows vehicle 202, intersection 502, real-world object 504, and visible space 512. In this situation, the visible space 512 of vehicle 202 may not be limited by the real-world object 504, depending on the positional relationship of vehicle 202 to intersection 502. Therefore, the visible space 512 may be limited by the range of vehicle 202's sensors. Thus, the visible space 512 is shown as a rectangle extending to the full range of vehicle 202's sensors.

[0100] Figure 6A is a diagram 600 of an example of identifying a virtual road user location, also referred to as generating at least one virtual road user in operation 404. This example shows a vehicle 202, an intersection 502, a real-world object 504, a visible space 506, a virtual road user 602 with a predicted trajectory 604, and a virtual road user 606 with a predicted trajectory 608. As vehicle 202 approaches intersection 502, the visible space 506 of vehicle 202 becomes restricted. For this reason, the visible space 506 may be considered trapezoidal as described above. Process 400 may generate a virtual road user because the sensor range of the vehicle may not extend beyond the minimum distance mentioned with respect to operation 418 of process 400. The virtual road user may be generated at the edge of the boundary of the visible space 506 of vehicle 202. For example, virtual road user 602 is generated along the outer right edge of the visible space 506, within the relevant lane. When a virtual road user 602 is generated, process 400 may also generate a predicted trajectory 604. Furthermore, along the left edge of the visible space 506, process 400 may also generate another virtual road user 606, as well as a predicted trajectory 608.

[0101] Figure 6B is a diagram 610 of an example in which the most relevant virtual road user is determined in operation 404. Diagram 610 shows a vehicle 202, an intersection 502, a real-world object 504, a virtual road user 602 with a predicted trajectory 604, a virtual road user 606 with a predicted trajectory 608, a planned trajectory 612 for vehicle 202, a time interval 614 for the predicted trajectory 604, and a time interval 616 for the predicted trajectory 608. The most relevant virtual road user is determined by finding the lane that is crossed first. As vehicle 202 approaches intersection 502 along the planned trajectory 612, the vehicle may cross the path of virtual road user 606 (e.g., predicted trajectory 608) at interval 616A. The time interval can be measured using any appropriate unit of time. In this example, the time interval is measured in seconds. When vehicle 202 crosses the predicted trajectory 608, the interval 616A may be 3s from virtual road user 606 in one example. As vehicle 202 continues along the planned track 612, vehicle 202 may cross the path of virtual road user 602 (e.g., predicted track 604) at interval 614A. Interval 614A represents a time 6s from virtual road user 602. Therefore, the lane that crosses intersection 502 earliest is the lane associated with virtual road user 606. Thus, virtual road user 606 is considered the most relevant road user in action 404, and the time to contact is 3s.

[0102] Furthermore, determining the most relevant virtual road user may use the distance to the interaction between the host vehicle and the predicted trajectory, in addition to the time interval. For example, given two predicted trajectories for two corresponding virtual road users, both predicted trajectories may have the same time interval (e.g., the host vehicle's planned trajectory may cross both virtual road user's predicted trajectories at the same time). If the time intervals between the host vehicle and the virtual road users are equal, the distance to the interaction between the host vehicle and the predicted trajectory may be used to determine the most relevant virtual road user.

[0103] Figures 7A and 7B illustrate an example of generating a virtual stop line in operation 408 of process 400. The virtual stop line may represent the closest point to the intersection where the host vehicle can stop without entering the intersection (for example, based on speed limits and lack of visibility for the host vehicle). Diagram 700 in Figure 7A is an example of generating a virtual stop line when the host vehicle has a planned trajectory to cross an intersection with a speed limit of 25 miles per hour or less. Diagram 700 shows a vehicle 202, an intersection 502, a real-world object 504, a virtual road user 602 with a predicted trajectory 604, a virtual road user 606 with a predicted trajectory 608, a virtual stop line 702, and an offset 704. As the vehicle 202 approaches the intersection 502, process 400 determines where to generate the virtual stop line 702 according to operation 408. For example, if vehicle 202 has a planned trajectory for crossing intersection 502 at a predetermined speed or less (e.g., a speed of 25 miles per hour or less), the virtual stop line 702 may be created with a first predetermined offset, for example, an offset of 6 m 704, from the predicted trajectory of the most relevant virtual road user (in this example, the predicted trajectory 608 of virtual road user 606).

[0104] Diagram 710 in Figure 7B is an example of generating a virtual stop line when the host vehicle has a planned trajectory to cross an intersection at a speed greater than a predetermined speed of 25 miles per hour in this example. Diagram 710 shows a vehicle 202, an intersection 502, a real-world object 504, a virtual road user 602 with a predicted trajectory 604, a virtual road user 606 with a predicted trajectory 608, a virtual stop line 712, and an offset 714. In this example, the vehicle 202 has a planned trajectory to cross the intersection 502 at a speed greater than the predetermined speed, and the virtual stop line 712 may be created with a second predetermined offset as the offset 714. The second predetermined offset is greater than the first predetermined offset. In this example, the second predetermined offset is 6.5 m.

[0105] Diagrams 700 and 710 show two scenarios, but there may be more or fewer scenarios than the first scenario (i.e., diagram 700) in which vehicle 202 crosses intersection 502 and the second scenario (i.e., diagram 710) in which vehicle 202 enters intersection 502 by turning left. For example, vehicle 202 may have a planned trajectory for completing a right turn at intersection 502. The principles applied to the new scenario are the same as those for the previous scenario, but the offsets may change. Thus, the new scenario may have a new set of offsets defined specifically for the new scenario.

[0106] Figure 8 is a diagram 800 of an example in which a target speed limit is determined according to operation 414 of process 400. Diagram 800 shows a vehicle 202, an intersection 502, a real-world object 504, a virtual road user 606 (in this example, the most relevant virtual road user), a predicted trajectory 608 of the virtual road user 606, a planned trajectory 612 of the vehicle 202 (also called the host vehicle), and a target speed limit 802. As the vehicle 202 approaches the intersection 502, the most relevant virtual road user (i.e., virtual road user 606) has already been determined in operation 404 of process 400. In operation 410, process 400 determines that it may not be necessary to stop at the virtual stop line 702 (shown in Figure 7A). Process 400 determines the target speed limit 802 according to operation 414 described above. More specifically, the target speed limit may be determined using the minimum values ​​of equations (1) and (2). If the time to contact is 4 seconds and the relative distance to the most relevant virtual vehicle is 40 meters, the equation may also be expressed by equation (3). min((relDist - 30) * 1.5 / 50, (TTC - 3) * 1.5 / 5)

[0107] In this example, the variable relDist could be 40m, and the variable TTC could be 4s.

[0108] Figure 9 illustrates another device or system 900 for vehicle control using edging and virtual stop line generation, as implemented in this disclosure. System 900 may represent a software pipeline for a vehicle such as vehicle 100 in Figure 1. System 900 includes a world model 902, a route planner 904, a predictive trajectory planner 906, and a control system 908. Other examples of system 900 may include more, fewer, or other components. In some examples, the components may be combined, and in other examples, the components may be divided into multiple components. System 900 does not need to be implemented in a vehicle; instead, system 900 may be implemented entirely or partially by a remote assistance control system, such as a remote assistance control system operating on a server computing device 234. Since system 900 is similar to system 300, redundant descriptions are omitted unless contextually desirable.

[0109] World model 902 is similar to world model 302 in Figure 3. Thus, world model 902 receives sensor data and tracks and maintains the projected trajectories of objects (e.g., real-world objects, hazardous objects, etc.) and moving objects. World model 902 may be used by operation 402 in Figure 4 to generate virtual objects 902A and predicted trajectories 902B associated with each of the virtual objects 902A, which are moving objects. In the above example, virtual objects 902A may include virtual road users 602 and virtual road users 606, and predicted trajectories 902B may include predicted trajectory 604 for virtual road user 602 and predicted trajectory 608 for virtual road user 606.

[0110] The output of the world model 902, for example, the virtual object 902A and the predicted trajectory 902B, provides input to the route planner 904. The route planner 904 in Figure 9 may incorporate the functions of the route planner 304 and the decision module 306 in Figure 3. Thus, the route planner 904 may generate a strategic speed plan 904A based at least partially on the virtual object 902A and the predicted trajectory 902B. The strategic speed plan 904A may include a set of discrete speed targets for different parts of the vehicle traffic network 208 along the host vehicle's route. The strategic speed plan 904A, the virtual object 902A, and the predicted trajectory 902B may be passed to the predictive trajectory planner 906.

[0111] The predictive trajectory planner 906 may function similarly to the predictive trajectory planner 308 in Figure 3. That is, the predictive trajectory planner 906 can determine a detailed planned trajectory for a host vehicle based on operations 404 to 420 in Figure 4. The predictive trajectory planner 906 receives a strategic speed plan 904A, a virtual object 902A, and a predicted trajectory 902B as input. Using one or more virtual road users 906A and their corresponding trajectories, the predictive trajectory planner 906 determines the most relevant virtual road user in operation 404, determines the TTC in operation 406, and generates a virtual stop line 906B in operation 408. The predictive trajectory planner 906 may then use this information to modify the strategic speed plan 904A in the edging module 906C, if necessary, by determining or setting a target speed in operation 414 or operation 414 and / or 420.

[0112] The target speed may be output to the control system 908 for use in controlling the host vehicle. The control system 908 may be the controller 114 in Figure 1. The control system 908 may be an ADAS such as an automatic braking system. The control system 908 may receive the target speed limit from the predictive trajectory planner 906. The control module may use the target speed limit to operate the host vehicle (i.e., vehicle 202). For example, the predictive trajectory planner 906 may determine that the host vehicle must stop at the virtual stop line 702 based on the most relevant virtual road user (e.g., virtual road user 606), the TTC, and the relative distance to the virtual stop line 702. In such a case, the target speed is set to stop the host vehicle in operation 412. Alternatively, the predictive trajectory planner 912 may use this information to determine that the host vehicle should proceed beyond the virtual stop line 702 (e.g., edging) at the reduced speed determined in action 414 to ensure there are no obstacles in the path, and then accelerate to match the strategic speed plan 904A if possible (e.g., in action 420). The control system 908 may operate the host vehicle using the target speed in action 422, including deceleration and / or braking. Instead of implementing the control system 908 in the controller 114, the control system 908 can remotely control the host vehicle.

[0113] In this specification, the terms “passenger,” “driver,” or “operator” may be used interchangeably. Similarly, the terms “braking” or “deceleration” may be used interchangeably. Where used herein, the terms “processor,” “computer,” or “computing device” include any unit or combination of units capable of performing any method disclosed herein, or any part or part thereof.

[0114] As used herein, the term “instruction” may include instructions or expressions for performing any method, or any part or part thereof, disclosed herein, and may be implemented in hardware, software, or any combination thereof. For example, an instruction may be implemented as information such as a computer program stored in memory, which may be executed by a processor to perform each of the methods, algorithms, embodiments, or combinations thereof described herein. In some implementations, an instruction, or part thereof, may be implemented as a dedicated processor or circuit which may include dedicated hardware for performing any of the methods, algorithms, embodiments, or combinations thereof described herein. In some implementations, parts of an instruction may be distributed across multiple processors on a single device or across multiple devices, which may be communicated directly or via a network such as a local area network, a wide area network, the Internet, or a combination thereof.

[0115] As used herein, the terms “example,” “embodiment,” “implementation,” “aspect,” “feature,” or “element” indicate that they serve as examples, cases, or illustrations. Unless expressly indicated otherwise, any example, embodiment, implementation, aspect, feature, or element is independent of any other example, embodiment, implementation, aspect, feature, or element and may be used in combination with any other example, embodiment, implementation, aspect, feature, or element.

[0116] As used herein, the terms “determine” and “identify,” or any variation thereof, include selecting, verifying, calculating, searching, receiving, determining, establishing, obtaining, or otherwise identifying or determining in any way using one or more devices as shown or described herein.

[0117] As used herein, the term “or” is intended to mean inclusive “or” rather than exclusive “or.” That is, unless otherwise specified or the context clearly indicates otherwise, “X contains A or B” is intended to indicate any of its natural inclusive permutations. If X contains A, if X contains B, or if X contains both A and B, “X contains A or B” satisfies any of the above cases. In addition, the articles ("a" and "an") used in this application and the attached claims should generally be interpreted as meaning “one or more” unless otherwise specified or the context makes it clear that they refer to a singular form.

[0118] Furthermore, for the sake of simplicity, the drawings and descriptions herein may include sequences or series of actions or stages, but the elements of the methods disclosed herein may occur in various orders or simultaneously. Furthermore, the elements of the methods disclosed herein may occur together with other elements not expressly presented and described herein. Furthermore, not all of the elements of the methods described herein may be required to implement the method in accordance with this disclosure. Although embodiments, features, and elements are described herein in specific combinations, each embodiment, feature, or element may be used independently or in various combinations, with or without other embodiments, features, and / or elements.

[0119] While the disclosed technology has been described in relation to specific embodiments, it should be understood that the disclosed technology is not limited to the disclosed embodiments, but rather is intended to encompass a variety of modifications and equivalent configurations that fall within the scope of the appended claims, and that its scope should be given the broadest possible interpretation under the law to include all such modifications and equivalent configurations.

Claims

1. To generate at least one virtual road user, wherein the location of each of the at least one virtual road users corresponds to the boundary of the range of a host vehicle's sensor approaching an intersection in the traffic network, Determining the most relevant virtual road user among the at least one virtual road user, wherein the most relevant virtual road user is associated with the lane that crosses the intersection earliest from the perspective of the host vehicle. The method for determining the time to contact with the most relevant virtual road user is to determine the time to contact based on the acceleration of the host vehicle, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant road user. Based on the time to contact and the relative distance, a target speed for the host vehicle is determined. The host vehicle is operated using the target speed as input to the control system of the host vehicle. Methods that include...

2. To generate a virtual stop line for the host vehicle, wherein the virtual stop line represents the position closest to the intersection where the host vehicle can stop before entering the intersection, In response to determining that the acceleration of the host vehicle is less than the minimum acceleration, or that the time to contact is less than the minimum contact time, the host vehicle is stopped at the virtual stop line. The method according to claim 1, including the method described in claim 1.

3. The method according to claim 2, wherein the nearest location is determined based on the speed limit of the road on which the host vehicle is traveling, and whether the host vehicle is merging into a lane of the road or crossing the road.

4. The method according to claim 1, wherein the target speed is based on the minimum value of a first equation using the relative distance and a second equation using the time to contact.

5. The method according to claim 1, wherein the range of the sensor of the host vehicle increases as the host vehicle approaches the intersection.

6. Receiving a strategic speed plan, When the range of the sensor of the host vehicle exceeds the minimum distance, the target speed is increased to match the strategic speed plan. The method according to claim 5, including the method described in claim 5.

7. If the distance to at least one virtual road user exceeds the minimum distance, increase the target speed to match the strategic speed plan. The method according to claim 6, including the method described in claim 6.

8. Determining the most relevant virtual road user is: To generate the planned trajectory of the host vehicle, Determining the first speed limit associated with each virtual road user of the at least one virtual road user, Calculate the distance between the host vehicle and each of the at least one virtual road users, Based on the planned track, the first speed limit, and the distance, the virtual road user that interacts with the host vehicle earliest among the at least one virtual road user is determined to be the most relevant virtual road user. The method according to claim 1, including the method described in claim 1.

9. To generate at least one virtual road user, wherein the location of each of the at least one virtual road users corresponds to the boundary of the range of a host vehicle's sensor approaching an intersection in the traffic network, Determining the most relevant virtual road user among the at least one virtual road user, wherein the most relevant virtual road user is associated with the lane that crosses the intersection earliest from the perspective of the host vehicle. The method for determining the time to contact with the most relevant virtual road user is to determine the time to contact based on the acceleration of the host vehicle, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant road user. Based on the time to contact and the relative distance, a target speed for the host vehicle is determined. The host vehicle is operated using the target speed as input to the control system of the host vehicle. A device comprising a processor configured to perform the following actions.

10. The aforementioned processor, To generate a virtual stop line for the host vehicle, wherein the virtual stop line represents the position closest to the intersection where the host vehicle can stop before entering the intersection, In response to determining that the acceleration of the host vehicle is less than the minimum acceleration, or that the time to contact is less than the minimum contact time, the host vehicle is stopped at the virtual stop line. The apparatus according to claim 9, configured to perform the following:

11. The apparatus according to claim 9, wherein the target speed is based on the minimum value of a first equation using the relative distance and a second equation using the time to contact.

12. The aforementioned processor, Receiving a strategic speed plan, When the range of the sensor of the host vehicle exceeds the minimum distance, the target speed is increased to match the strategic speed plan. The apparatus according to claim 9, configured to perform the following:

13. The aforementioned processor, Receiving a strategic speed plan, When the distance to at least one virtual road user exceeds the minimum distance, the target speed is increased to match the strategic speed plan. The apparatus according to claim 9, configured to perform the following:

14. Determining the most relevant virtual road user is: To generate the planned trajectory of the host vehicle, Determining the first speed limit associated with each virtual road user of the at least one virtual road user, Calculate the distance between the host vehicle and each of the at least one virtual road users, Based on the planned track, the first speed limit, and the distance, the virtual road user that interacts with the host vehicle earliest among the at least one virtual road user is determined to be the most relevant virtual road user. The apparatus according to claim 9, including

15. A non-temporary computer-readable medium that stores instructions capable of causing one or more processors to perform an action, wherein the action is: To generate at least one virtual road user, wherein the location of each of the at least one virtual road users corresponds to the boundary of the range of a host vehicle's sensor approaching an intersection in the traffic network, Determining the most relevant virtual road user among the at least one virtual road user, wherein the most relevant virtual road user is associated with the lane that crosses the intersection earliest from the perspective of the host vehicle. The method for determining the time to contact with the most relevant virtual road user is to determine the time to contact based on the acceleration of the host vehicle, the predicted trajectory of the most relevant virtual road user, and the relative distance between the host vehicle and the most relevant road user. Based on the time to contact and the relative distance, a target speed for the host vehicle is determined. The host vehicle is operated using the target speed as input to the control system of the host vehicle. Non-temporary computer-readable media, including [specific examples of such media].

16. The aforementioned operation is, To generate a virtual stop line for the host vehicle, wherein the virtual stop line represents the position closest to the intersection where the host vehicle can stop before entering the intersection, In response to determining that the acceleration of the host vehicle is less than the minimum acceleration, or that the time to contact is less than the minimum contact time, the host vehicle is stopped at the virtual stop line. A non-temporary computer-readable medium according to claim 15, including the following:

17. The non-temporary computer-readable medium according to claim 16, wherein the nearest location is determined based on the speed limit of the road on which the host vehicle is traveling, and whether the host vehicle is merging into a lane of the road or crossing the road.

18. The aforementioned operation is, Receiving a strategic speed plan, When the range of the sensor of the host vehicle exceeds the minimum distance, the target speed is increased to match the strategic speed plan. A non-temporary computer-readable medium according to claim 15, including the following:

19. The aforementioned operation is, Receiving a strategic speed plan, When the distance to at least one virtual road user exceeds the minimum distance, the target speed is increased to match the strategic speed plan. A non-temporary computer-readable medium according to claim 15, including the following:

20. Determining the most relevant virtual road user is: To generate the planned trajectory of the host vehicle, Determining the first speed limit associated with each virtual road user of the at least one virtual road user, Calculate the distance between the host vehicle and each of the at least one virtual road users, Based on the planned track, the first speed limit, and the distance, the virtual road user that interacts with the host vehicle earliest among the at least one virtual road user is determined to be the most relevant virtual road user. A non-temporary computer-readable medium according to claim 15, including the following:

Images