Method for intersection entry of self-control vehicle and self-control vehicle
By coordinating data elements between vehicles in the autonomous vehicle, determining the target space and manipulating the vehicle entry, the coordination problem of the autonomous vehicle entering at the intersection is solved, and a safe and efficient traffic flow is achieved.
Patent Information
- Application Number
- CN202510334629.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2019-08-20
- Filing Date
- 2020-04-14
- Publication Date
- 2025-05-30
AI Technical Summary
The prior art is difficult to effectively coordinate the entry of autonomous vehicles at intersections, especially when it is necessary to optimize vehicle spacing and maneuvering plans.
By implementing a vehicle coordination method in an autonomous vehicle, a wireless transceiver receives and transmits data elements, including identification, autonomous vehicle status and braking distance data, determines the target space, and manipulates the vehicle into the target space by responding to a message.
It realizes safe and efficient entry of autonomous vehicles at intersections, optimizes vehicle spacing and manipulation plans, and improves the efficiency and safety of traffic flow.
Smart Images

Figure CN120071674A_ABST
Abstract
Description
[0001] This application is a divisional application of the patent application for invention with the application date of April 14, 2020, application number 202080030616.7, and invention title "Method and apparatus for vehicle maneuver planning and messaging". Technical Field
[0002] The subject matter disclosed herein relates to automotive equipment, and more particularly to a method for a self-driving vehicle to enter an intersection, a self-driving vehicle, and a non-transitory computer-readable medium. Background Art
[0003] Autonomous vehicles enable self-driving to enhance the safety, efficiency, and convenience of in-vehicle transportation. The path and maneuver planning for vehicles with vehicle-to-everything (V2X) capabilities (referred to herein as self-driving vehicles) depends on the ability to understand the capabilities and behaviors of surrounding vehicles. The capabilities and behaviors of surrounding vehicles help determine, for example, safe inter-vehicle spacing and lane change maneuvers. It will be necessary to communicate the capabilities and behaviors of surrounding vehicles via a set of data elements (DEs) for vehicles, for example, through V2X application layer standards, to exchange capability information. Using these data elements will enable vehicles to optimize the time and distance for inter-vehicle spacing and maneuvers. It should be understood that, as used herein, references to vehicle-to-everything (V2X) and cellular vehicle-to-everything (CV2X) may apply to and cover various communication embodiments and standards, such as but not limited to 5G new radio (NR) communication standards, dedicated short-range communication (DSRC), 802.11p, ground vehicle standards (SVS) from the Society of Automotive Engineers (SAE) of the United States, intelligent transportation system (ITS) standards from the European Telecommunications Standards Institute (ETSI), such as basic safety messages or cooperative awareness messages, and / or other vehicle-to-vehicle (V2V), cellular vehicle-to-everything (CV2X), and other vehicle-to-everything (V2X) communication embodiments that may exist or be defined in the future. Summary of the Invention
[0004] Some exemplary techniques are presented herein that can be implemented in various methods and apparatuses in a vehicle to determine, send, receive, and utilize data elements to determine inter-vehicle spacing, intersection priority, lane change behavior and spacing, and other autonomous vehicle behaviors.
[0005] In an embodiment, a vehicle coordination method may include: receiving, at an autonomous vehicle, a first message from a first vehicle, where the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; receiving, at the autonomous vehicle, a second message from a second vehicle, where the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; determining a target space at least in part based on the size of the autonomous vehicle, the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status data element for the second vehicle, the braking distance data element for the first vehicle, the braking distance data element for the second vehicle, or a combination thereof; sending a third message from the autonomous vehicle to the first vehicle to request the target space between the first vehicle and the second vehicle; sending a fourth message from the autonomous vehicle to the second vehicle to request the target space between the first vehicle and the second vehicle; receiving at least one response from the fifth message from the first vehicle, the sixth message from the second vehicle, or a combination thereof; and maneuvering the autonomous vehicle into the target space between the first vehicle and the second vehicle based on the at least one response.
[0006] In an embodiment, an autonomous vehicle may include: one or more wireless transceivers; vehicle interior sensors; vehicle exterior sensors; a memory; and one or more processors communicatively coupled to the one or more wireless transceivers, the vehicle interior sensors, the vehicle exterior sensors, and the memory; wherein the one or more processors are configured to: receive, at the one or more wireless transceivers, a first message from a first vehicle, wherein the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; receive, at the one or more wireless transceivers, a second message from a second vehicle, wherein the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; determine a target space at least in part based on the size of the autonomous vehicle, the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status data element for the second vehicle, the braking distance data element for the first vehicle, the braking distance data element for the second vehicle, or a combination thereof; send a third message from the one or more wireless transceivers to the first vehicle to request the target space between the first vehicle and the second vehicle; send a fourth message from the one or more wireless transceivers to the second vehicle to request the target space between the first vehicle and the second vehicle; receive at least one response from the fifth message from the first vehicle or the sixth message from the second vehicle or a combination thereof; and maneuver the autonomous vehicle into the target space between the first vehicle and the second vehicle based on the at least one response.
[0007] In an embodiment, an autonomous vehicle may include: components for receiving a first message from a first vehicle at the autonomous vehicle, where the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; components for receiving a second message from a second vehicle at the autonomous vehicle, where the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; components for determining a target space at least in part based on the size of the autonomous vehicle, the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status data element for the second vehicle, the braking distance data element for the first vehicle, the braking distance data element for the second vehicle, or a combination thereof; components for sending a third message from the autonomous vehicle to the first vehicle to request the target space between the first vehicle and the second vehicle; components for sending a fourth message from the autonomous vehicle to the second vehicle to request the target space between the first vehicle and the second vehicle; components for receiving at least one response from a fifth message from the first vehicle or a sixth message from the second vehicle or a combination thereof; and components for maneuvering the autonomous vehicle into the target space between the first vehicle and the second vehicle based on the at least one response.
[0008] In an embodiment, a vehicle coordination method may include: receiving, at an autonomous vehicle, a first message from a first vehicle, where the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; receiving, at the autonomous vehicle, a second message from a second vehicle, where the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; determining a first target space between the autonomous vehicle and the first vehicle based on the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the first vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; determining a second target space between the autonomous vehicle and the second vehicle based on the autonomous vehicle status data element for the second vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the second vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; sending a third message from the autonomous vehicle to the first vehicle to request the first target space between the first vehicle and the autonomous vehicle; sending a fourth message from the autonomous vehicle to the second vehicle to request the second target space between the first vehicle and the second vehicle; receiving at least one response from the fifth message from the first vehicle or the sixth message from the second vehicle, or a combination thereof; and manipulating the autonomous vehicle based on the received at least one response to create or maintain the first target space between the autonomous vehicle and the first vehicle and the second target space between the autonomous vehicle and the second vehicle.
[0009] In an embodiment, an autonomous vehicle may include: one or more wireless transceivers; vehicle interior sensors; vehicle exterior sensors; a memory; and one or more processors communicatively coupled to the one or more wireless transceivers, the vehicle interior sensors, the vehicle exterior sensors, and the memory; wherein the one or more processors are configured to: receive a first message at the one or more wireless transceivers from a first vehicle, wherein the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; receive a second message at the one or more wireless transceivers from a second vehicle, wherein the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; determine a first target space between the autonomous vehicle and the first vehicle based on the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the first vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; determine a second target space between the autonomous vehicle and the second vehicle based on the autonomous vehicle status data element for the second vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the second vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; send a third message from the one or more wireless transceivers to the first vehicle to request the first target space between the first vehicle and the autonomous vehicle; send a fourth message from the one or more wireless transceivers to the second vehicle to request the second target space between the first vehicle and the second vehicle; receive at least one response in a fifth message from the first vehicle or a sixth message from the second vehicle or a combination thereof at the one or more wireless transceivers; and manipulate the autonomous vehicle based on the received at least one response to create or maintain the first target space between the autonomous vehicle and the first vehicle and the second target space between the autonomous vehicle and the second vehicle.
[0010] In an embodiment, an autonomous vehicle may include: components for receiving a first message from a first vehicle at the autonomous vehicle, where the first message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof; components for receiving a second message from a second vehicle at the autonomous vehicle, where the second message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof; components for determining a first target space between the autonomous vehicle and the first vehicle based on the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the first vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; components for determining a second target space between the autonomous vehicle and the second vehicle based on the autonomous vehicle status data element for the second vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the second vehicle, or the braking distance of the autonomous vehicle, or a combination thereof; components for sending a third message from the autonomous vehicle to the first vehicle to request the first target space between the first vehicle and the autonomous vehicle; components for sending a fourth message from the autonomous vehicle to the second vehicle to request the second target space between the first vehicle and the second vehicle; components for receiving at least one response in a fifth message from the first vehicle or a sixth message from the second vehicle or a combination thereof at the autonomous vehicle; and components for manipulating the autonomous vehicle based on the received at least one response to create or maintain the first target space between the autonomous vehicle and the first vehicle and the second target space between the autonomous vehicle and the second vehicle. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The following non - limiting and non - exhaustive aspects are described with reference to the accompanying drawings, where like element symbols refer to like parts throughout the views, unless otherwise indicated.
[0012] Figure 1 is a diagram of an apparatus showing an exemplary embodiment for determining and communicating values of V2X capability data elements based on vehicle internal and external sensors, vehicle capabilities, and external V2X inputs.
[0013] Figure 2 is a diagram of an apparatus showing an exemplary embodiment for determining and communicating a vehicle stopping distance based on vehicle internal and external sensors, vehicle capabilities, and external V2X inputs.
[0014] Figure 3A and Figure 3B show an exemplary process of a lane change of an autonomous vehicle.
[0015] Figure 4A andFigure 4B Shows an exemplary process of a lane change of a non-autonomous vehicle.
[0016] Figure 5A and Figure 5B Shows an exemplary process of a lane change of a vehicle with autonomous mode turned off.
[0017] Figure 6A and Figure 6B Shows an exemplary process for determining and announcing the stopping distance of a platooning vehicle.
[0018] Figure 7A and Figure 7B Shows an exemplary process for a vehicle to determine the stopping distance at an intersection and announce the maneuver.
[0019] Figure 8A and Figure 8B Shows an exemplary process for determining vehicle behavior at an intersection in the presence of environmental conditions such as surface water hazards.
[0020] Figure 9 Shows an exemplary system-level embodiment for an autonomous vehicle.
[0021] Figure 10 Shows an exemplary physical embodiment for an autonomous vehicle.
[0022] Figure 11 Shows an exemplary system-level embodiment for an autonomous vehicle to perform V2X autonomous vehicle sensing, prediction, planning, and execution.
[0023] Figure 12 Shows an exemplary system-level embodiment for an autonomous vehicle to perform V2X autonomous vehicle sensing, prediction, planning, and execution using ability data elements.
[0024] Figure 13A and Figure 13B Shows the exchange of vehicle autonomous ability messaging to achieve a closer inter-vehicle spacing.
[0025] Figure 14 Shows the exchange of vehicle autonomous ability messaging to achieve a closer inter-vehicle spacing.
[0026] Figure 15A and Figure 15B Shows the exchange of vehicle non-autonomous ability messaging to achieve a safe inter-vehicle spacing.
[0027] Figure 16 Shows the exchange of vehicle non-autonomous ability messaging to achieve a safe inter-vehicle spacing.
[0028] Figure 17Shows the stopping distance of an exchanged vehicle announcement to determine the spacing between platooned vehicles.
[0029] Figure 18 Shows the stopping distance of an exchanged vehicle announcement to determine the spacing between platooned vehicles.
[0030] Figure 19A and Figure 19B Shows the exchange of stopping distance information so that surrounding vehicles can stop and emergency vehicles can cross the intersection.
[0031] Figure 20 Shows the exchange of stopping distance information so that surrounding vehicles can stop and emergency vehicles can cross the intersection.
[0032] Figure 21A and Figure 21B Shows the exchange of stopping distance information so that surrounding vehicles that can stop can stop, while the emergency vehicle can decelerate before passing through the intersection so that surrounding vehicles that cannot stop can cross the intersection before the emergency vehicle.
[0033] Figure 22 Shows the exchange of stopping distance information so that surrounding vehicles that can stop can stop, while the emergency vehicle can decelerate before passing through the intersection so that surrounding vehicles that cannot stop can cross the intersection before the emergency vehicle.
[0034] Figure 23 Shows a method of vehicle communication for lane change.
[0035] Figure 24 Shows a method of vehicle communication for requesting the spacing between a vehicle and an adjacent vehicle.
[0036] Figure 25 Shows a method of vehicle communication with a roadside unit. Detailed Description
[0037] Some exemplary techniques are presented herein that may be implemented in a vehicle in various methods, manners, and apparatuses. The exemplary techniques presented herein illustrate various methods and apparatuses in a vehicle to enable the determination and use of vehicle-to-everything (V2X) data elements. The exemplary techniques described herein are generally applicable to V2X capability data elements (DEs) that enable V2X vehicle capabilities and are not currently defined by V2X application layer standards, which include metrics of autonomous or non-autonomous driving, stopping distance, acceleration, turning radius at current speed, and / or maneuverability at current speed. These DEs may be applied to V2X messages, such as messages defined by the Society of Automotive Engineers (SAE) ground vehicle standards (SVS) or messages defined by the European Telecommunications Standards Institute (ETSI) intelligent transportation systems (ITS) standards, such as basic safety messages or cooperative awareness messages. Exemplary techniques and embodiments are provided for determining and providing these data elements. In an embodiment, the vehicle is capable of using vehicle sensor data related to sensed static or dynamic conditions and using external V2X inputs (such as data elements from other vehicles) to dynamically update or adjust the values of the capability data elements to determine the internal vehicle state, behavior, and external environmental conditions and to provide the latest data elements over-the-air (OTA) to nearby vehicles.
[0038] In an embodiment, some exemplary V2X data elements may include whether the vehicle is being driven autonomously or non-autonomously (e.g., based on the vehicle state stored in memory or determined upon request), the vehicle stopping distance, the vehicle acceleration, and the vehicle turning radius at current speed and / or a metric of maneuverability at current speed. In an embodiment, the V2X data element that describes whether the vehicle is being driven autonomously or non-autonomously may be predetermined based on automotive capabilities, particularly based on whether the vehicle is capable of autonomous driving. However, for a vehicle capable of autonomous driving, the autonomous driving capability may be deactivated for the manual driving mode. In some embodiments, the autonomous driving capability may be manually deactivated by the driver of the vehicle, by turning off the autonomous driving mode, or by taking driving-related actions (such as adjusting the steering, applying acceleration, or applying brakes). In some embodiments, when the vehicle encounters a situation that it is not adequately equipped to drive into, the autonomous driving mode may be deactivated by the vehicle; in an embodiment, a manual mode switch may be accompanied by a notification to the driver that the autonomous driving mode may or should be terminated and in some embodiments it may also be required that the driver confirm that the driver is able to control the vehicle before initiating the shift out of the autonomous mode. The data element may include, for example, the vehicle state in the autonomous mode or the vehicle state in the manual mode (or other non-autonomous mode). The data element may be used to describe details regarding the termination of the autonomous mode; for example, including whether the autonomous mode was manually cancelled by the driver or automatically terminated due to adverse conditions or other reasons such that the vehicle cannot drive autonomously in the autonomous mode.
[0039] In an embodiment, the vehicle stopping distance can be estimated based on predetermined factory specifications and / or test data stored in a memory such as non-volatile RAM / ROM or a hard disk drive in the vehicle. In an embodiment, the vehicle stopping distance can be estimated based on internal and external sensor measurements, vehicle capabilities, and external V2X inputs. In an embodiment, the vehicle stopping distance can be estimated based on a combination of predetermined factory specifications and / or test data and predetermined vehicle specifications, as well as internal and external sensor measurements, vehicle capabilities, and / or external V2X inputs.
[0040] In an embodiment, the vehicle acceleration can be estimated based on predetermined factory specifications and / or test data stored in a memory such as non-volatile RAM / ROM or a hard disk drive in the vehicle. In an embodiment, the acceleration can be estimated based on internal and external sensor measurements, vehicle capabilities, and external V2X inputs. In an embodiment, the vehicle acceleration can be estimated based on both a combination of predetermined factory specifications and / or test data and predetermined vehicle specifications, as well as internal and external sensor measurements, vehicle capabilities, and / or external V2X inputs.
[0041] In an embodiment, the turning radius of the vehicle at the current speed and / or a measure of the maneuverability at the current speed can be estimated based on predetermined factory specifications and / or test data stored in a memory such as non-volatile RAM / ROM or a hard disk drive in the vehicle. In an embodiment, the turning radius of the vehicle at the current speed and / or a measure of the maneuverability at the current speed can be estimated based on internal and external sensor measurements, vehicle capabilities, and external V2X inputs. In an embodiment, the turning radius of the vehicle at the current speed and / or a measure of the maneuverability at the current speed can be estimated based on both a combination of predetermined factory specifications and / or test data and predetermined vehicle specifications, as well as internal and external sensor measurements, vehicle capabilities, and / or external V2X inputs.
[0042] Figure 1 Systems and components are shown for implementing the various methods, apparatuses, and techniques described in the figures and background herein. In an embodiment, the vehicle can include various vehicle external sensors (100), such as cameras 935, LIDAR 950, radar 953, rain and weather sensors 945, GNSS receivers 970, and data provided from a WAN or other communication network via a wireless transceiver 930, such as map data and weather conditions. In an embodiment, measurement data from the various vehicle external sensors 100 and input sources such as cameras 935, LIDAR 950, radar 953, rain and weather sensors 945, GNSS receivers 970, as well as map data, can be utilized to determine data elements that can be shared between the host (autonomous) vehicle and other vehicles and / or other network-connected devices.
[0043] In a vehicle, there may be multiple cameras 935. For example, in an embodiment, there may be a camera in the front window assembly associated with the rearview mirror, a camera in the front bumper, cameras in both the exterior rearview side mirrors (connected to the front passenger door) and the trunk assembly and / or the rear bumper, which in some embodiments will present a full 360-degree view around the vehicle and / or near and far viewpoints. One or more cameras may be present in various vehicle embodiments. The camera 935 can be used to determine and verify the distance between the vehicle and an external object, such as to determine lane change and stop positions. The camera can also be used to determine weather and road conditions, such as to determine or verify that the road is wet based on the reflectivity of the road surface. This data can be used alone or in combination with wheel sensor data such as from traction control sensors, accelerometers, and / or gyroscopes to determine, for example, the slipperiness of the road surface, which can be used to increase the estimated stopping distance. The combination of wheel and traction control sensors and camera data can also be used for further determination with respect to water and / or ice on the road surface, and the quality or type of the road surface (asphalt, concrete, dirt, or gravel). In various embodiments, the camera can also be used to determine weather conditions, day and night, and other external conditions.
[0044] The LIDAR 950 can be implemented in a central roof-mounted unit, or the LIDAR 950 can be implemented using multiple smaller units, for example, using solid-state LIDAR 950 sensors, and oriented in a specific direction. The LIDAR 950 can be used to determine the distance between the vehicle and an external object, and can also be used in combination with other sensors such as GNSS receivers 970 or other position sensors, cameras, wheel tick / distance sensors, and other position and distance-related sensors to measure and / or verify the stopping distance and / or measure and / or calibrate the stopping response relative to the applied braking force. The LIDAR 950 measurements can also be used in combination with tire pressure sensors, brake pad sensors, and other tire-related sensors to predict and / or adjust the stopping distance estimate and / or braking performance characteristics; for example, with respect to a nominally defined braking distance, based on predefined braking pressure characteristics, the LIDAR 950 can be used to measure the in-situ relationship between the braking force, tire pressure, and actual stopping performance, which will be related to the ground and weather such that the braking distance can increase due to adverse weather conditions such as wet or icy roads and / or different road surfaces.
[0045] The tire pressure, as measurable by various wheel sensors 1012 or other sensors 945, affects the stopping distance and acceleration. The tire pressure affects the amount of contact between the tire surface and the road or other driving surface, thereby affecting the stopping distance, acceleration, and the handling and operation required to maneuver the vehicle. The tire pressure also affects tire wear and tread life. For example, an over-inflated tire may exhibit a significant increase in stopping distance. For instance, a 20% increase in tire pressure may cause up to a 20% increase in stopping distance, depending on the tire, tread, actual pressure, and road surface. On the other hand, despite the increased tread-road contact, a tire that is 20% under-inflated may exhibit little or no decrease in stopping distance due to the effect of less force on each applied surface when the tire surface is applied to the road surface. Since the actual interaction between the tire surface and the road surface will vary depending on tire pressure, environmental factors such as temperature, road composition, and other factors, LIDAR 950, radar 953, GNSS 970, object-to-object signal-based measurements (e.g., based on signal strength or signal timing, such as RTT or TOA), or other distance measurement sensors can be used to determine the current acceleration and braking performance by observing the real-time effect of brake application on acceleration and deceleration. Additionally, during actual traffic-related acceleration and braking, LIDAR 950, radar 953, GNSS, and / or RTT, TOA, RSSI, or other signal-based measurements (e.g., using wireless transceiver 930 based on vehicle-to-vehicle messaging signals) can be used to determine the selection of different braking and / or acceleration methods that are most suitable for weather, environmental, and road conditions by real-time monitoring and, if necessary, through test acceleration and braking for determining current parameters.
[0046] In an embodiment, the turning radius of the vehicle at the current speed and / or a measure of the maneuverability at the current speed will depend on the speed, with the turning radius increasing with speed and the maneuverability decreasing with speed. The turning radius of the vehicle at the current speed and / or a measure of the maneuverability at the current speed are also affected by road conditions; (e.g., slipperiness increases the turning radius and decreases the maneuverability at the current speed). An increase in road traction decreases the turning radius at the current speed and increases the maneuverability at the current speed; a decrease in road traction will exhibit the opposite. Increased tire inflation reduces the contact of the tire surface with the road, thereby reducing traction and thus increasing the turning radius of the vehicle at the current speed and decreasing the maneuverability at the current speed. Sufficient tire tread increases road traction and thus decreases the turning radius at the current speed and increases the maneuverability at the current speed. An increase in vehicle weight increases the turning radius at the current speed and decreases the maneuverability at the current speed. Uneven load distribution increases the turning radius at the current speed and decreases the maneuverability at the current speed. The turning radius of the vehicle at the current speed and the measure of the maneuverability at the current speed can be determined based on some or all of these variables, and / or can be monitored in real time relative to the current conditions using external and internal sensors (e.g., to monitor loss of tire traction and tire slippage relative to the road surface and / or relative to other tires).
[0047] In an embodiment, the radar 953 can be implemented in a fender / bumper assembly 1108, where the fender / bumper is made of a non-metallic material such as plastic or fiberglass, which provides good forward coverage for radar signals and good signal penetration of the fender in the forward direction. Additional radar assemblies 953 can be added for rearward coverage via the rear bumper. In an embodiment, the radar 953 can be implemented in other forward ways, such as embedding or attaching the antenna to / into, for example, the windshield. The assembly is typically isolated from the environment by plastic (such as a plastic bumper or other radar-transparent material). Some vehicle embodiments may also have rearward radar. As with LIDAR, in an embodiment, radar-based distance measurements relative to an object at a known or fixed position can be used to determine performance characteristics of the vehicle, such as braking performance relative to applied pressure and acceleration relative to a specific throttle curve. LIDAR 950 can be combined with or radar can be used instead of LIDAR for distance determination for brake calibration and acceleration calibration and / or for determination of braking and acceleration distances at a specific speed. For example, in the presence of snow, fog, rain, or other visually obscuring conditions, radar can replace or supplement LIDAR 950 and / or camera-based methods.
[0048] The measure of braking performance can be determined by the ratio of the distance traveled over elapsed time when applying a specific braking curve or pressure. Another measure of braking performance includes determining and / or estimating the stopping distance from the current speed to zero speed. The distance measurement from various systems such as LIDAR, radar, wheel rotation, and / or GNSS can be used in various ways to determine the distance required to stop from the current speed. Even if a complete stop is not measured, the distance traveled by the vehicle while applying brakes to decelerate the vehicle can be used to estimate and / or proportionally increase or decrease the estimated stopping distance at the current speed. In some embodiments, an additional margin can be applied to the estimated stopping distance at the current speed to provide a safety margin.
[0049] Redundant and / or complementary ways of measuring position and distance can be particularly applicable to determining braking performance on wet or icy roads in weather conditions where visual methods such as cameras are impaired and non-visual sensor systems such as radar and wheel rotation can be used to provide distance estimates. As discussed, braking performance and stopping distance can be estimated by measuring the distance and speed impacts of applying various brakes at pressures and frequencies, and the braking performance and stopping distance can be used to estimate an appropriate braking distance for the condition and optimize the brake actuator application strategy. Fixed objects or objects at known locations can be used as reference points and can include vehicles at known locations, road markings, signs, trees, buildings, and other reference objects visible to the sensor system. The vehicle can initiate test brakes and / or accelerations to characterize the surface and / or braking / acceleration performance and / or optimize the braking strategy and / or steering strategy and determine an appropriate braking distance and determine the driving strategy.
[0050] Measurements based on camera 935 and LIDAR 950 and / or sensors such as accelerometer and gyroscope measurements can be used to determine and characterize handling performance, such as the amount of steering at any given speed achieved by applying a known force or a known degree of wheel rotation through the steering system. Like braking and acceleration, handling performance also depends on conditions including effects such as weather, road surface, road and / or ambient temperature, as well as tire tread, tire pressure, and other vehicle factors. The characterized performance of the vehicle relative to the current conditions can be used to determine vehicle performance parameters such as braking performance and stopping distance, acceleration, and turning radius and / or maneuverability at the current speed. These parameters can be used to determine a safe inter-vehicle spacing with respect to acceleration, braking, and handling. Additionally, when determining the inter-vehicle spacing, the performance of adjacent and nearby vehicles can also be utilized such that a vehicle with a longer braking distance (e.g., a truck) following a vehicle with a shorter braking distance (e.g., a motorcycle) will add an additional braking distance to account for the better performance of the vehicle ahead relative to the self-driving vehicle to avoid a collision in the case where the vehicle ahead decelerates faster than the vehicle behind. Similarly, a vehicle with a shorter braking distance following a vehicle with a longer braking distance can at least theoretically utilize a positive performance increment to achieve a closer vehicle spacing, for example, to optimize the overall vehicle spacing and traffic flow.
[0051] Rain, light, and weather sensors, as well as various other sensors 945, may also be present in some vehicles and, in some embodiments, are part of the instrument panel and / or front window assembly or under-hood assembly. Other weather-related information can also be received from external sources such as other vehicles, roadside weather repeaters, and via a data connection (such as 4G and 5G data connections) to weather and roadside condition monitoring and information delivery services. Weather-related sensors can also be adapted to control the weighting and / or use of various sensor measurements. For example, vision-based measurements from a camera can be reduced in weight relative to radar measurements in dark conditions. In cases where vision measurements are occluded, such as in extreme weather (such as heavy rain, heavy snow, and / or hail or thick fog), LIDAR 950 and camera measurements can be reduced in weight or even ignored, favoring reducing the impact on systems such as radar on the vehicle.
[0052] In an embodiment, in addition to using tire traction sensors (such as antilock, traction control, and all-wheel drive traction control related sensor systems 945) for traction control, antilock braking, and all-wheel drive systems, the tire traction sensors can also be utilized to estimate the road surface condition, which can be used at least in part to estimate the braking distance or modify the nominal braking distance estimate. In an embodiment, the empirically derived braking estimate or other braking estimates can be increased based on an estimate of road slipperiness. Thus, a road surface condition that produces more tire slippage as measured by traction control or other tire systems can increase the braking distance estimate more than a road surface condition that produces little or no tire slippage. In an embodiment, the estimate of road slippage can be measured and the braking distance estimate can be increased in proportion to the amount of road slippage (loss of tire traction). In an embodiment, the estimate can be classified as being below or above a threshold for tire slippage, which can affect the braking estimate by a predetermined amount.
[0053] GNSS 970 is typically implemented in a roof-mounted antenna assembly, such as in the shark fin antenna assembly 1002 on the rear of the roof. Especially in open-air conditions, GNSS can be used to determine absolute and relative positions and speeds (e.g., using Doppler measurements or by using continuous position and time measurements) and also to determine speed changes (such as based on the Doppler change over time from consecutive measurement signals from the same GNSS satellite). The relative position can be determined via the difference between consecutive absolute positions via trilateration of the GNSS constellation and / or by comparing the changes in Doppler and / or phase offset of the GNSS signals at consecutive times / positions. Especially in open-air conditions, GNSS-based relative position and speed measurements can be sufficient to characterize vehicle capabilities, such as braking performance and acceleration with respect to specific road conditions and / or vehicle states (tire inflation, brake pad wear, fluid state, and motion states such as current speed and / or forward direction, yaw). Doppler-based speed measurements can be determined over time and are related to curve braking and acceleration performance for parameters such as braking or acceleration to be determined (such as applied braking force, braking application pattern, supplied fuel or energy, etc.) and / or for specific conditions inherent to the vehicle (such as brake pad thickness, applied pressure, tire inflation) and specific conditions not inherent to the vehicle (such as road conditions, weather conditions, etc.). In an embodiment, Doppler-based speed measurements and Doppler-based incremental speed measurements can be used to independently or in combination with other sensor systems (such as radar, LIDAR 950, and camera-based systems, as well as driveline-based systems such as wheel rotation and steering angle, accelerometers, and gyroscopes) to characterize the actual acceleration and braking performance of the vehicle.
[0054] Map data can be stored locally in a memory 960 such as a flash memory, RAM, ROM, disk drive, or other memory device and / or the map data can be obtained in batches or in real time and / or wirelessly updated from a map database accessible via a network connection using, for example, a wireless transceiver 930 over a wireless data network. The map data can be combined with sensor data and used to record map metadata, such as annotation changes of map location-based parameters and conditions. This map metadata information can be shared between vehicles to enable more accurate and earlier prediction of upcoming vehicle performance parameters and external conditions at any given location and / or shared with a map information server and / or a crowdsourcing server.
[0055] In an embodiment, vehicle 1000 will determine a capability value based on vehicle external sensors 100 (such as cameras, LIDAR, radar, rain, weather, GNSS, and map data), vehicle internal sensors 110 (such as tire pressure sensors, brake pad and brake status sensors, speed and forward direction, and yaw), vehicle capabilities 120 (such as stop / brake performance, and acceleration), and / or external V2X inputs 130 (such as external vehicle messaging and infrastructure (RSU) messaging). The capability value can be determined 140 as a function of the inputs, and the determined capability value can be used to update a V2X capability data element 150. In some embodiments, steps 140 and 150 can be performed using a processor 910 and / or a DSP 920 and a memory 960 and / or various combinations thereof, the processor and / or DSP and memory and / or various combinations thereof being configured to perform steps 140 and 150 using inputs from vehicle external sensors 100, vehicle internal sensors 110, vehicle capabilities 120, and / or external V2X inputs 130 or various combinations thereof. For example, in some embodiments, using step 160, V2X vehicle-to-vehicle communication, or other modes of vehicle-to-vehicle or vehicle-to-network communication, the capability data element can be shared with other vehicles or systems. It should be understood that this is an exemplary embodiment and the sensor types and capabilities can vary between different vehicles.
[0056] As Figure 2As shown, in an embodiment, vehicle 1000 may estimate a vehicle stopping distance and provide the estimate as a V2X data element via V2X vehicle-to-vehicle communication. In an embodiment, vehicle 1000 will determine the vehicle stopping distance based on vehicle external sensors 200 (such as cameras, LIDAR, radar, rain, weather, GNSS, and map data), vehicle internal sensors 210 (such as tire pressure sensors, brake pad and brake status sensors, speed and forward direction, and yaw), vehicle capabilities 220 (such as stop / brake performance, and acceleration), and / or external V2X inputs 230 (such as external vehicle messaging and infrastructure (RSU) messaging). Processor 910 and / or DSP 920 and memory 960 may be configured to update the value of the V2X capabilities data element for the vehicle stopping distance. The vehicle stopping distance may be determined 240 based on inputs from vehicle external sensors 200, vehicle internal sensors 210, vehicle capabilities 220, and / or external V2X inputs 230, and the determined vehicle stopping distance may be used to update the V2X capabilities data element 250. In some embodiments, steps 240 and 250 may be performed using processor 910 and / or DSP 920 and memory 960 and / or various combinations thereof, which are configured to perform steps 240 and 250 using various inputs from vehicle external sensors 200, vehicle internal sensors 210, vehicle capabilities 220, and / or external V2X inputs 230 or various combinations thereof. For example, in some embodiments, using step 260, V2X vehicle-to-vehicle communication, or other modes of vehicle-to-vehicle or vehicle-to-network communication, the capabilities data element may be shared with other vehicles or systems. It should be understood that this is an exemplary embodiment and the sensor types and capabilities may vary between different vehicles.
[0057] As Figure 3A and Figure 3B shown, in an embodiment, vehicle 1000 (e.g., car, truck, motorcycle, and / or other motor vehicle) may exchange vehicle autonomous capabilities to achieve a desired lane change maneuver in a situation of a closer vehicle spacing. In Figure 3A this, in an embodiment, vehicle A 300 intends to change lanes to the right from lane 3 to lane 2. Vehicles 305A, 305B, and 305C in lane 2 announce their autonomous driving capabilities. In an embodiment, each of the lane 2 vehicles (autonomous vehicles) sends a basic safety message (BSM) that includes data elements depicting driving the respective vehicle autonomously. In an embodiment, equivalent messaging may also be achieved using an ETSI cooperative awareness message (CAM) that includes data elements depicting driving the respective vehicle autonomously. Vehicle A 300 receives messages from vehicles 305A, 305B, and 305C in lane 2 that include data elements depicting driving the respective vehicle autonomously. InFigure 3B In this case, vehicle A 300 performs a lane change from lane 3 to lane 2, signals cars 305A, 305B, and 305C in lane 2 to request and / or announce the upcoming lane change, and then performs the lane change from lane 3 to lane 2, so as to insert itself between cars 315A and 315B with a reduced inter-vehicle spacing based on the announced autonomous capabilities of cars 315A and 315B in a non-autonomous situation relative to cars 315A and 315B.
[0058] As Figure 4A and Figure 4B shown in, in an embodiment, vehicle 1000 (such as a car, a truck, a motorcycle, and / or other motor vehicles) may receive (or infer) vehicle non-autonomous capability messages and / or information to achieve a desired lane change maneuver with a wider vehicle spacing relative to the vehicle spacing that autonomous vehicles such as Figure 3A and Figure 3B 305A, 305B, and 305C will utilize. In Figure 4A this case, in an embodiment, vehicle A 400 intends to make a left lane change from lane 3 to lane 4. Vehicles 410A, 410B, and 410C in lane 4 announce their non-autonomous driving capabilities. In an embodiment, each of the lane 4 vehicles (driving non-autonomously) 410A, 410B, and 410C sends a basic safety message (BSM), which includes data elements depicting the corresponding vehicle driving non-autonomously. In an embodiment, equivalent messaging may also be implemented using an ETSI cooperative awareness message (CAM), which includes data elements depicting the corresponding vehicle driving non-autonomously. Vehicle A 400 receives messaging from vehicles 410A, 410B, and 410C in lane 4, which includes data elements depicting the corresponding vehicle driving non-autonomously. In Figure 4B this case, vehicle 400 negotiates and performs a lane change from lane 3 to lane 4, signals vehicles 410A, 410B, and 410C in lane 4 to request and / or announce the upcoming lane change, and then performs the lane change from lane 3 to lane 4, so as to insert itself between cars 410A and 410B with an increased inter-vehicle spacing based on the announced non-autonomous capabilities of cars 410A and 410B relative to the inter-vehicle spacing that would be utilized in the case where cars 410A and 410B are announced as autonomous. In an embodiment, a detected but unresponsive car that does not provide BSM and / or CAM messaging response and / or announcement may be assumed to be non-autonomous.
[0059] As Figure 5A and Figure 5BAs shown, in an embodiment, vehicle 1000 (e.g., an automobile, truck, motorcycle, and / or other motor vehicle) may receive a vehicle non-autonomous capability message after receiving a vehicle autonomous capability message for a vehicle in a target lane, thereby causing vehicle A500 to delay or replan a lane change until a safe lane change gap is available, to which vehicle A500 will direct the lane change. In Figure 5A In, in an embodiment, vehicle A500 intends to change lanes to the right from lane 3 to lane 2. Vehicles 505A, 505B, and 505C in lane 2 announce their autonomous driving capabilities. In an embodiment, each of the lane 2 vehicles (driving autonomously) 505A, 505B, and 505C sends a basic safety message (BSM) that includes data elements depicting the respective vehicles being driven autonomously. In an embodiment, equivalent messaging may also be implemented using ETSI cooperative awareness messages (CAMs) that include data elements depicting the respective vehicles being driven autonomously. Vehicle A500 receives messages from vehicles 505A, 505B, and 505C in lane 2 that include data elements depicting the respective vehicles being driven autonomously. However, in Figure 5B In, the middle vehicle (vehicle 505B) in lane 2 turns off its autonomous capability or otherwise switches to a non-autonomous driving mode and sends a BSM or CAM message that changes the autonomous capability field to non-autonomous. Vehicle A500 receives a BSM or CAM message with the autonomous capability field set to non-autonomous and delays or replans the lane change to the right in response to the non-autonomous capability of vehicle 505B. For example, in an embodiment, vehicle A500 may wait for an appropriate gap for a non-autonomous lane change to the right or wait for adjacent autonomous vehicles to negotiate a lane change to the right. In an embodiment, a detected but unresponsive vehicle that does not provide BSM and / or CAM messaging responses and / or announcements may be assumed to be non-autonomous; e.g., vehicle 505B stops sending autonomous capabilities, and in an embodiment, vehicle A500 may infer that vehicle 505B is not (or no longer) being driven autonomously.
[0060] In an embodiment, exemplary data elements for autonomous and non-autonomous vehicle determination for lane changes or possible lane changes may be implemented as follows. The SAE data element definitions may include new data elements that include values for DE_DriverAutonomous and DE_DriverNonAutonomous. These values may be assigned to the existing SAE J2735 data element DE_BasicVehicleClass. In this embodiment, it assigns currently unused (reserved) values to represent the DriverAutonomous and DriverNonAutonomous data elements including V2X_DriverAutonomous and V2X_DriverNonAutonomous.
[0061] In an embodiment, the ETSI-ITS data element definition may include new data elements, which include values for DE_DriverAutonomous and DE_DriverNonAutonomous. In this embodiment, new values are assigned to the existing ETSI-ITS TS102 894-2 common data dictionary DE_StationType, thereby designating currently unused (reserved) values to represent values for autonomous and non-autonomous driving, which include V2X_DriverAutonomous and V2X_DriverNonAutonomous.
[0062] As Figure 6A and Figure 6B shown, in an embodiment, vehicle 1000 (such as a car, truck, motorcycle, and / or other motor vehicle) may announce a stopping distance, which in an embodiment may be used to determine the inter-vehicle spacing for platooning and other purposes, such as for autonomous lanes only to optimize traffic flow. The inter-vehicle spacing may vary depending on road conditions (such as dry roads, wet roads, icy roads, snowy roads, asphalt roads, concrete roads, dirt roads, or gravel roads).
[0063] In Figure 6A it is shown, in an embodiment, the inter-vehicle spacing under dry road conditions. Individual vehicles determine the stopping distance based on detected parameters, such as vehicle speed, detected road and / or weather conditions, inherent braking ability, vehicle internal state (e.g., tire pressure), and vehicle driving state such as autonomous or non-autonomous driving mode. BSM and / or CAM messaging or other inter-vehicle messaging is used to announce the stopping distance capability to nearby vehicles. Based on vehicle-to-vehicle V2X communication and coordination and / or with the assistance of a platooning server accessed via a wireless network connection, the inter-vehicle and / or platooning spacing and the announced stopping distance of each vehicle are obtained. As shown, larger vehicles (such as trucks) with longer stopping distances will maintain a larger inter-vehicle distance in front of them.
[0064] In Figure 6B it is shown, in an embodiment, the inter-vehicle spacing under wet road conditions. The road condition (water) detected by the vehicle causes an increased stopping distance to be announced in BSM and / or CAM messaging. Due to the detected road condition, the inter-vehicle spacing and / or platooning spacing and the announced stopping distance are larger. It should be understood that other adverse conditions that result in longer stopping distances (such as slippery or low-traction roads, icy roads, snow-covered roads, and dirt or gravel roads) will similarly cause an increased stopping distance to be announced in BSM and / or CAM messaging.
[0065] AsFigure 7A and Figure 7B As shown in Figure 7B , in an embodiment, a vehicle 1000 (e.g., a car, a truck, a motorcycle, and / or other motor vehicle) may announce a stopping distance, which in an embodiment may be used to determine whether a non-emergency vehicle can and will stop at an intersection of a passing emergency vehicle.
[0066] In Figure 7A As shown in Figure 7A , in an embodiment, a vehicle approaching an intersection is shown, where an emergency vehicle is approaching the same intersection. Emergency vehicle A broadcasts its required maneuvers to continue through the intersection as it approaches the intersection. Non-emergency vehicles B and C each use their respective positions and distances from the intersection, speeds, forward directions, detected road conditions, and / or stopping / braking capabilities or a combination thereof to determine their respective stopping distances, which in an embodiment may be used to determine whether each vehicle can stop before the intersection. If present, an infrastructure entity (e.g., a roadside unit (RSU)) may enhance the vehicle's knowledge of the environment (weather, road conditions, vulnerable road users (VRUs), etc.). In an embodiment, the calculated stopping distances may be used to update the BSM and / or CAM messaging data element values for the stopping distances.
[0067] In Figure 7B As shown in Figure 7B , in an embodiment, vehicles B and C are shown stopped at an intersection to allow emergency vehicle A to pass through the intersection. In an embodiment, emergency vehicle A negotiates with vehicles B and C. Vehicles B and C send their stopping distances and confirm their ability to stop at the intersection. Vehicles B and C stop at the intersection. Then, vehicle A continues through the intersection. In an embodiment, if vehicle B or C cannot stop, vehicle A will then stop or adjust its speed to avoid the non-stopping vehicle, as Figure 8A and Figure 8B shown.
[0068] As Figure 8A and Figure 8B shown in Figure 8A and Figure 8B , in an embodiment, a vehicle 1000 (e.g., a car, a truck, a motorcycle, and / or other motor vehicle) may announce a stopping distance, which in an embodiment may be used to determine whether a non-emergency vehicle can or cannot stop at an intersection of a passing emergency vehicle.
[0069] In Figure 8AIn an embodiment, a vehicle approaching an intersection is shown, where an emergency vehicle is approaching the same intersection. However, in this example, Vehicle C detects a road surface water hazard (or other road surface conditions that may affect its stopping ability, such as snow, ice, oil, dust, gravel, etc.) and may adjust its announced stopping distance by updating the BSM and / or CAM messaging data element values for the stopping distance. Emergency Vehicle A broadcasts its required maneuvers to continue through the intersection as it approaches. Non-emergency Vehicle B and Vehicle C each use their respective positions and distances from the intersection, speeds, forward directions, detected road conditions (Vehicle C detects ground water), and / or stopping / braking capabilities or combinations thereof to determine their respective stopping distances, which in the embodiment can be used to determine whether each vehicle can stop before the intersection. If so, an infrastructure entity (e.g., a roadside unit (RSU)) can enhance the vehicle's awareness of the environment (weather, road conditions, vulnerable road users (VRUs), etc.). In an embodiment, the calculated stopping distance can be used to update the BSM and / or CAM messaging data element values for the stopping distance.
[0070] In Figure 8B In an embodiment, Vehicle B is shown stopped at the intersection and Vehicle C continues through the intersection because it is determined that the vehicle cannot stop before the intersection to allow Emergency Vehicle A to cross. In an embodiment, Emergency Vehicle A negotiates with Vehicle B and Vehicle C. Vehicle B determines that it will be able to stop in real time and sends its stopping distance. Vehicle C determines that it cannot stop in real time due to the ground water hazard. Emergency Vehicle A negotiates with Vehicle B and Vehicle C. Vehicle B stops at the intersection while Vehicle C continues through the intersection. Vehicle A decelerates (or stops as needed) to allow Vehicle C to cross the intersection before continuing.
[0071] In an embodiment, new vehicle-to-everything (V2X) data element (DE) types can be added to vehicle-to-vehicle messaging. In an embodiment, these new V2X data element (DE) types can include autonomous and non-autonomous drivers, stopping distance, turning radius at speed, and / or acceleration at speed or various combinations thereof. In an embodiment, the dynamic adjustment of data element values using functional blocks can incorporate vehicle static conditions (e.g., tire pressure, brake pad wear, trailer or load), vehicle dynamic conditions (e.g., speed, forward direction, acceleration, yaw), vehicle inherent capabilities (e.g., braking, acceleration, turning radius), including externally sensed road conditions. In an embodiment, the new V2X data element types and dynamic adjustment of data element values can be implemented in V2X messaging according to standards such as SAE and ETSI-ITS.
[0072] As Figure 9As shown, in an embodiment, a vehicle 1000 (such as an automobile, a truck, a motorcycle, and / or other motor vehicles) can send radio signals to other vehicles 1000 and receive radio signals from other vehicles and / or from a wireless communication network, for example, via vehicle-to-vehicle (V2X) communication. In one example, the vehicle 1000 can communicate with other vehicles and / or a wireless communication network via a wide area network (WAN) transceiver 930 and a wireless antenna 932 by sending wireless signals to or receiving wireless signals from a remote wireless transceiver 930. The remote wireless transceiver can include another vehicle 1000', a base transceiver station subsystem (BTS), a Node B, an evolved Node B (eNodeB), or a next-generation Node B (gNodeB) on a wireless communication link. Similarly, the vehicle 1000 can send wireless signals to or receive wireless signals from a local transceiver on a wireless communication link, for example, by using a wireless local area network (WLAN) and / or a personal area network (PAN) transceiver 930 and a wireless antenna 932. In an embodiment, the wireless transceiver 930 can include various combinations of WAN, WLAN, and / or PAN transceivers. In an embodiment, the local transceiver can also be a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceivers. In an embodiment, the vehicle 1000 can send wireless signals to or receive wireless signals from a wireless transceiver 930 on the vehicle 1000 via a wireless communication link 934. The local transceiver, the WAN wireless transceiver, and / or the mobile wireless transceiver can include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, a home Node B (HNB), or a home eNodeB (HeNB), or a next-generation eNodeB (gNodeB) and can provide access to a wireless local area network (WLAN, for example, an IEEE 802.11 network), a wireless personal area network (PAN, for example, a network), or a cellular network (for example, an LTE network or other wireless wide area network, such as the LTE network or other wireless wide area network discussed in the next paragraph). Of course, it should be understood that these are merely examples of networks that can communicate with a vehicle via a wireless link, and the claimed subject matter is not limited in this regard. It should also be understood that the wireless transceiver 930 can be located on various vehicles 1000, ships, ferries, automobiles, buses, drones, and various transportation vehicles. In an embodiment, the vehicle 1000 can be used for passenger transportation, package transportation, or other purposes. In an embodiment, GNSS signals 974 from GNSS satellites are used by the vehicle 1000 for position determination. In an embodiment, signals 934 from the WAN transceiver, the WLAN, and / or the PAN local transceiver are used alone or in combination with the GNSS signals 974 for position determination.
[0073] Examples of network technologies that can support wireless transceiver 930 are Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Long Term Evolution (LTE), 5th Generation Wireless (5G) or New Radio Access Technology (NR), High Rate Packet Data (HRPD), and V2X vehicle-to-vehicle communication. V2X can be defined by various standards such as SAE, ETS-ITS standards. GSM, WCDMA, and LTE are technologies defined by 3GPP. CDMA and HRPD are technologies defined by the 3rd Generation Partnership Project 2 (3GPP2). WCDMA is also part of the Universal Mobile Telecommunications System (UMTS) and can be supported by HNB.
[0074] Wireless transceiver 930 can communicate with a communication network via a WAN wireless base station, which can include equipment deployment that provides subscribers of the service access to the wireless communication network (e.g., under a service contract). Here, the WAN wireless base station can perform the functions of a wide area network (WAN) or a cell base station when maintaining subscriber equipment within a cell, and this function is determined at least in part based on the range within which the WAN wireless base station can provide access services. Examples of WAN base stations include GSM TM , WCDMA TM , LTE TM , CDMA TM , HRPD TM , WiFi TM , BT, WiMax TM and / or 5th Generation (5G) base stations. In an embodiment, other wireless base stations can include Wireless LAN (WLAN) and / or PAN transceivers.
[0075] In an embodiment, vehicle 1000 can contain multiple wireless transceivers, including WAN, WLAN, and / or PAN transceivers. In an embodiment, radio technologies that can support wireless communication links further include Wireless Local Area Network (e.g., WLAN, e.g., IEEE 802.11), Bluetooth TM (BT) and / or ZigBee TM .
[0076] In an embodiment, vehicle 1000 may include one or more cameras 935. In an embodiment, the camera may include a camera sensor and a mounting assembly. Different mounting assemblies may be used for different cameras on vehicle 1000. For example, a front camera may be mounted in the front bumper, in the stem of the rearview mirror assembly, or in other front regions of vehicle 1000. A rear camera may be mounted in the rear bumper / fender, on the rear windshield, in the trunk of the vehicle, or on other rear regions. Side cameras may be mounted on the sides of the vehicle, such as integrated into the mirror assembly or the door assembly. The cameras may provide object detection and distance estimation for objects having a known size and / or shape (e.g., both stop signs and license plates have standardized sizes and shapes), and may also provide information about rotational motion relative to the axis of the vehicle, such as during a turn. When used in conjunction with other sensors, the cameras may be calibrated by using other systems, such as by using LIDAR, wheel encoders / distance sensors, and / or GNSS, to verify the distance traveled and the angular orientation. The cameras may similarly be used to verify and calibrate other systems to verify that the distance measurements are correct, for example, by calibrating against known distances between known objects (landmarks, roadside markings, road mile markers, etc.), and also to verify that object detection is performed accurately such that the objects are thus mapped to the correct positions relative to the vehicle by LIDAR and other systems. Similarly, when combined with, for example, an accelerometer, the impact time of a road hazard (the elapsed time before hitting, for example, a pothole) may be estimated, which may be verified against the actual impact time and / or against a stopping model (e.g., comparing the estimated stopping distance in the case of attempting to stop before hitting an object) and / or a maneuvering model (verifying that the current estimates of the metrics for the turning radius at the current speed and / or the maneuverability at the current speed are accurate for the current conditions and thus modifying to update the estimation parameters based on camera and other sensor measurements).
[0077] In an embodiment, an accelerometer, a gyroscope, and a magnetometer 940 may be used to provide and / or verify motion and orientation information. The accelerometer and the gyroscope may be used to monitor wheel and driveline performance. In an embodiment, the accelerometer may also be used to verify the actual time of impact of a road hazard, such as a pothole, relative to a predicted time, based on existing stopping and acceleration models and a steering model. In an embodiment, the gyroscope and the magnetometer may be used to measure the rotational state of the vehicle and the orientation relative to magnetic north, respectively, and in particular when used in conjunction with measurements from other external and internal sensors (such as other sensors 945, such as speed sensors, wheel encoder sensors) and / or odometer measurements, to measure and calibrate the estimates and / or models of the metrics for the turning radius at the current speed and / or the maneuverability at the current speed.
[0078] Light Detection and Ranging (LIDAR) uses pulsed lasers to measure distances to objects. While cameras can be used for object detection, LIDAR provides a way to more deterministically detect the distance to an object, particularly with respect to objects of unknown size and shape. LIDAR measurements can also be used to estimate stopping distances at different speeds and in different conditions by providing accurate distance measurements and incremental distance measurements, which can be measured during braking and / or acceleration in embodiments to determine the actual stopping distance and / or acceleration distance, which can be used directly or is likely to be used to calibrate predictive stopping, turning, and acceleration models. For example, measurements of stopping distance at 25 miles per hour and possibly also of the stopping curve with respect to time and braking pressure can be used as inputs to vary the estimate of stopping performance at other speeds (such as at 60 mph). These estimates can be made as estimates based on sensor measurements or as changes to curves determined in a reference condition or applied to curves determined in a reference condition. Similar estimates can be made for acceleration and maneuverability to adjust a particular model or apply changes to a model to estimate performance in a given road, environment, and vehicle condition.
[0079] Memory 960 can be used with processor 910 and / or DSP 920 and can include flash memory, RAM, ROM, disk drives, or flash cards or other memory devices or various combinations thereof. In an embodiment, memory 960 can contain instructions for implementing the various methods described throughout this description. In an embodiment, the memory can contain instructions for estimating stopping distances, maneuverability, and acceleration parameters. In an embodiment, the memory can contain instructions for operating and calibrating sensors and for receiving maps, weather, vehicle (vehicle 1000 and surrounding vehicles), and other data and for using the data and measurements from various internal and external sensors to determine performance parameters (such as stopping distance, acceleration at the current speed, and turning radius and / or maneuverability at the current speed) and to determine operating parameters (such as inter-vehicle distance, turning initiation / timing and performance, and initiation / timing of merging operations into traffic).
[0080] In an embodiment, the power and drive systems (generator, battery, transmission, engine) and associated systems 975 and systems (brakes, actuators, throttle control, steering, and electrical) 955 may be controlled by a processor and / or hardware or software, or by the vehicle operator, or by some combination thereof. The systems (brakes, actuators, throttle control, steering, electrical, etc.) 955 and the power and drive or other systems 975 may be used in conjunction with performance parameters and operating parameters to autonomously (and manually, with respect to alerts and emergency overrides / brakes / stops) safely and accurately drive and operate the vehicle 1000 so as to safely, effectively, and efficiently merge into traffic, stop the vehicle 1000, accelerate the vehicle, and otherwise operate the vehicle.
[0081] A Global Navigation Satellite System (GNSS) receiver may be used to determine a position relative to the Earth (absolute position) and, when used in conjunction with other information such as measurements and / or mapping data from other objects, to determine a position relative to other objects (such as relative to other vehicles and / or relative to the road surface).
[0082] The GNSS receiver 970 may be used to determine a position that can be used to calibrate other sensors, which, when appropriate, such as for determining the distance between two time points under clear sky conditions and using that distance data to calibrate other sensors such as an odometer and / or LIDAR. GNSS Doppler measurements may also be used to determine the linear and rotational motion of the vehicle, which may be used in conjunction with gyroscopes and / or magnetometers and other sensor systems to maintain the calibration of these systems based on measured position data.
[0083] Radio Detection and Ranging (RADAR) 953 uses transmitted radio waves reflected from objects. The reflected radio waves are analyzed based on the time it takes for the reflection to arrive and other signal characteristics of the reflected wave to determine the position of nearby objects. Radar 953 may be used to detect the position of nearby vehicles, roadside objects (signs, other vehicles, pedestrians, etc.) and will generally achieve object detection even in inclement weather such as snow, rain, or hail. Thus, when vision-based systems typically fail, radar 953 may be used to supplement the LIDAR 950 system and camera 935 system by providing ranging and distance measurements and information and providing ranging information to other objects. Additionally, radar 953 may be used to calibrate and / or sanity check other systems such as LIDAR 955 and camera 935. The ranging measurements from radar 953 may be used to determine / measure the stopping distance, acceleration, maneuverability at the current speed, and / or the turning radius at the current speed and / or a metric of the maneuverability at the current speed.
[0084] As Figure 10As shown, in an embodiment, vehicle 1000 may have cameras, such as camera 1006 mounted on the rearview mirror, a camera mounted on the front fender (not shown in the figure), a camera mounted on the side mirror (not shown in the figure), and a rear camera (not shown in the figure, but typically on the trunk, hatch, or rear bumper). Vehicle 1000 may also have LIDAR 1004, which is used to detect objects and measure distances to these objects; LIDAR 1004 is often mounted on the roof. However, if there are multiple LIDAR units, they may be oriented around the front, rear, and sides of the vehicle. Vehicle 1000 may have various other position-related systems, such as a GNSS receiver (usually in the shark fin unit on the rear of the roof), various wireless transceivers (such as WAN, WLAN, V2X; usually but not necessarily in the shark fin) 1002, radar 1008 (usually in the front bumper), and SONAR 1010 (usually on the sides of the vehicle, if present). There may also be various wheel 1012 and driveline sensors, such as tire pressure sensors, accelerometers, gyroscopes, and wheel rotation detection and / or counters. It should be appreciated that in the embodiment of vehicle 1000, this list is not intended to be restrictive and Figure 10 is intended to provide typical locations of various sensors. Additionally, reference Figure 9 is made to another detail regarding a specific sensor.
[0085] As Figure 11 shown, in an embodiment, vehicle 1000 may receive vehicle and environmental information from vehicle external sensors 1102, vehicle internal sensors 1104, vehicle capabilities 1106, external V2X inputs 1108 from the environment, from other vehicles, from system servers, and / or from vehicle motion states 1110 (describing current and / or future motion states). The received vehicle and environmental information may be processed in one or more processors 910, DSP 920, and memory in an embodiment, and the one or more processors, DSP, and memory are connected and configured to provide external object sensing and classification, prediction and planning, and actuation execution, as well as to determine and update V2X capability data element values and transmit V2X messaging including the determined data elements via one or more wireless transceivers 930 (such as via a V2X transceiver). The messaging and data elements may be sent and received via various means, protocols, and standards (such as via SAE or ETSI SV2X messages and data elements or other wireless protocols supported by wireless transceiver 930).
[0086] The V2X capability data element value determination block 1128 includes a block 1130 for determining a capability value as a function of inputs and a block 1132 for updating the V2X capability data element and forwarding the V2X capability data element to the V2X vehicle - to - vehicle negotiation of block 1124, which vehicle - to - vehicle negotiation can communicate various V2X data elements and V2X vehicle requests and communications via the wireless transceiver 930. The block 1130 for determining the capability value based on the inputs receives inputs from blocks 1102, 1104, 1106, 1108, and 1110, which inputs include, in an embodiment, internal and external sensors, capabilities, external V2X inputs, and / or vehicle motion states. For example, in an embodiment, the inputs can include vehicle external sensors 1102, vehicle internal sensors 1104, vehicle capabilities 1106, external V2X inputs 1108, and / or vehicle motion states 1110. Based on and / or in accordance with the inputs described above and other vehicle - related input sources (such as servers 1255, 1245, 1260, 1250, and 1240, which provide, for example, vehicle information, routes, position assistance, map data, and environmental data, and provide inputs and / or supplement other inputs and / or are used in combination with other inputs, other inputs such as road position data, map data, driving condition data, and other vehicle - related data inputs), the autonomous vehicle determines the capability value, which the vehicle determines as a function 1130 of the inputs. The capability value provided by block 1130 is determined as a function of the inputs from blocks 1102, 1104, 1106, 1108, and / or 1110 and is provided to update the V2X capability data element in block 1132, where the capability data element is determined and formatted for V2X vehicle - to - vehicle messaging. Blocks 1130 and 1132 can be implemented using various dedicated or general - purpose hardware and software, such as using processor 910 and / or DSP 920 and memory 960, or in an embodiment can be implemented in a dedicated hardware block such as a dedicated sensor processing and / or vehicle messaging core. In an embodiment, blocks 1102, 1104, 1106, 1108, and 1110 can have dedicated processing cores or can share processing with blocks 1130 and 1132.
[0087] In some embodiments, the vehicle external sensors 1102 may include cameras 1006, LIDAR 1004, radar 1008, proximity sensors, rain sensors, weather sensors, GNSS receivers 1002, and received data used with the sensors, such as map data, environmental data, location, route, and / or other vehicle information, which may be received, for example, from other vehicles, devices, and servers (such as, in embodiments, map server 1250, route server 1245, vehicle information server 1255, environmental data server 1240, location server 1260) and / or from associated devices (such as mobile device 1200, which may be present in or near a vehicle such as vehicle A 1280). It should be understood that there may be one or more cameras. In embodiments, the cameras may be front-facing, side-facing, rear-facing, or adjustable in view (such as a rotatable camera). In embodiments, there may be multiple cameras 1006 facing the same plane. For example, cameras 1006 may include two front cameras, one camera focusing on lower objects and / or a lower view for parking purposes (such as mounted on the bumper), and one camera focusing on a higher view to track traffic, other vehicles, pedestrians, and farther objects. In embodiments, the various views may be stitched and / or correlated with other inputs such as V2X inputs from other vehicles to optimize tracking of other vehicles and external entities and objects and / or to calibrate the sensor systems against each other. LIDAR 1004 may be mounted on the roof and rotatable, or focused on a specific view (such as front, rear, side). LIDAR 1004 may be solid-state or mechanical. Proximity sensors may be ultrasonic, radar-based, light-based (such as infrared range finding), and / or capacitive (ground-touch orientation or capacitive detection of a metallic body). Rain and weather sensors may include various sensing capabilities and technologies, such as atmospheric pressure sensors, moisture detectors, rain sensors, and / or light sensors and / or may make use of other pre-existing sensor systems. GNSS receivers may be mounted on the roof, such as in a fin antenna assembly mounted at the rear of an automobile roof, on the hood or dashboard, or otherwise placed outside or inside the vehicle.
[0088] In embodiments, the vehicle internal sensors 1104 may include wheel sensors 1012, such as tire pressure sensors, brake pad sensors, brake status sensors, speedometers and other speed sensors, forward direction sensors, and / or orientation sensors (such as magnetometers and geomagnetic compasses), distance sensors (such as odometers and wheel scale sensors), inertial sensors (such as accelerometers and gyroscopes and inertial positioning results using the sensors mentioned above), and yaw, pitch, and / or roll sensors (which may be determined individually or as using other sensor systems such as accelerometers, gyroscopes, and / or tilt sensors).
[0089] Both the vehicle interior sensor 1104 and the vehicle exterior sensor 1102 may have shared or dedicated processing capabilities. For example, a sensor system or subsystem may have one or more sensor processing cores that determine vehicle state values, such as yaw, pitch, roll, forward direction, speed, acceleration capabilities, and / or distance and / or stopping distance, based on measurements and other inputs from accelerometers, gyroscopes, magnetometers, and / or other sensing systems. Different sensing systems may communicate with each other to determine measurement values or send values to block 1130 to combine measurement values and determine capability values based on the inputs. Vehicle state values derived from measurements from the internal and external sensors may be further combined with vehicle state values and / or measurements from other sensor systems using a general-purpose or application processor. For example, blocks 1130, 1132, and / or 1124 may be implemented on a dedicated or centralized processor to determine data element values for V2X messaging, which may be transmitted using wireless transceiver 930 or via other communication transceivers. In an embodiment, sensors may be partitioned into related systems, such as LIDAR, radar, motion, wheel systems, etc., which are processed by dedicated cores such that the raw results from each core output vehicle state values that are combined and interpreted to derive combined vehicle state values that include capability data elements and state data elements, which may be used to control or otherwise affect vehicle operation and / or be used as messaging steps shared with other vehicles and / or systems via V2X or other messaging capabilities. In an embodiment, these messaging capabilities may be based on a variety of wireless-related, optical-related, or other communication standards, such as those supported by wireless transceiver 930 and antenna 932.
[0090] In an embodiment, vehicle capabilities 1106 can include performance estimates for stopping, braking, accelerating, and turning radius, and autonomous and / or non-autonomous states and / or capabilities. In an embodiment, the capability estimates can be formula-based or can be based on stored estimates that can be loaded into a memory in an embodiment. In an embodiment, the stored estimates can be based on empirical performance numbers for a particular vehicle or for an average across one or more vehicles and / or for one or more models for a given performance profile. Where performance estimates for multiple models are averaged or otherwise combined, they can be selected based on similar or common characteristics. For example, vehicles with similar or the same weight and the same or similar drivetrains can share performance estimates for drive performance-related estimates such as braking / stopping distance, turning radius, and acceleration performance. For example, external V2X inputs 1108 can also be used to obtain vehicle performance estimates via a wireless network from a vehicle data server on a network. This is particularly useful for obtaining information about vehicles that do not have wireless capabilities and cannot directly provide vehicle information. In an embodiment, vehicle capabilities 1106 can also be affected by automotive component states such as tire wear, tire brand capabilities, brake pad wear, brake brand and capabilities, and engine state. In an embodiment, vehicle capabilities 1106 can also be affected by the overall automotive state such as speed, forward direction and by external factors such as road surface, road conditions (wet, dry, slipperiness / traction), weather (high winds, rainy, snowy, black ice, slippery roads). In many cases, wear or other system degradation and external factors such as weather, road surface, road conditions, etc. can be used to reduce, validate, or improve performance estimates when determining the capability value as a function of the inputs 1130. Similarly, in an embodiment, brand-related performance such as installing tires with better traction, such as snow tires for a winter snow environment, can be used to change or improve performance or inhibit performance degradation. In an embodiment, multiple factors such as those mentioned above can be combined to estimate performance and determine the capability value as a function of the inputs 1130. In some embodiments, the actually measured vehicle performance such as measuring vehicle stopping distance and / or acceleration time per distance segment can be measured and / or estimated based on actual vehicle driving-related performance. In an embodiment, if the measurements are inconsistent, more weight can be given to the most recently measured performance or priority can be given relative to older measurements. Similarly, in an embodiment, current measurements detected by an autonomous vehicle (such as via vehicle external sensors 1102 and / or vehicle internal sensors 1104) during similar conditions on, for example, the same type of weather or the same type of road surface can be more heavily weighted and / or given priority in determining the capability value as a function of the inputs 1130.
[0091] If the determined capability value of the function determined as an input in block 1130 is provided to block 1132, the V2X capability data element transmitted via block 1124 (V2X vehicle - to - vehicle negotiation) is updated, which can be implemented via various means (such as communication on wireless transceiver 930 and using various V2X messaging standards, such as via SAE or ETSI SV2X messages and data elements). In an embodiment, one or more processors 910 and / or DSP 920 and memory 960 and the systems or components described herein can be connected and configured to execute the processes described with respect to Figure 11 and throughout this specification. The capability value 1130 of the function as an input can be modified into a different data format and / or unit and / or other conversions or combinations that may be required for one or more capability values before being used as a V2X capability data element. In an embodiment, the adjustment of the data format and / or unit and / or the conversion or combination of one or more capability values can be performed in processor 910 and update the V2X capability data element block 1132 or elsewhere in the architecture.
[0092] V2X vehicle sensing, prediction, and plan execution 1112 partially utilizes sensor fusion and object classification block 1114 to correlate, validate, and / or combine data from input blocks 1102, 1104, 1106, 1108, and 1110 to handle the reception and processing of information from blocks 1102, 1104, 1106, 1108, and 1110. The external object sensing and classification block 1114 determines the objects present, determines the type of the objects (cars, trucks, bicycles, motorcycles, pedestrians, animals, etc.) and / or the object state relative to the self-driving vehicle, such as the moving state, proximity, direction of travel relative to the self-driving vehicle, size, danger level, and vulnerability priority (e.g., pedestrians will have a higher vulnerability priority relative to road debris). The output from this block 1114 can be provided to the prediction and planning block 1118, which determines the detected objects and vehicles and their associated trajectories via block 1120 and determines the vehicle maneuvers and path plans in block 1122. The output of this block 1122 is used directly or via the V2X vehicle-to-vehicle negotiation block 1124 for vehicle maneuver execution in block 1126, which will integrate and consider the maneuver plans, positions, and states received from other vehicles. The V2X vehicle-to-vehicle negotiation considers the states of neighboring vehicles and enables negotiation and coordination among neighboring or otherwise affected vehicles based on vehicle priorities, vehicle capabilities (such as the ability to stop, decelerate, or accelerate to avoid collisions), and in some embodiments based on various conditions (such as weather conditions (rainy, foggy, snowy, windy), road conditions (dry, wet, icy, slippery)). These include, for example, negotiation of the timing and order of crossing intersections between cars approaching an intersection, negotiation of lane changes between adjacent cars, negotiation for parking spaces, negotiation for making a directed movement or passing another vehicle on a single-lane road. Vehicle-to-vehicle negotiation can also include time-based and / or distance-based factors, such as reservation times, destination distances, and estimated route times to reach the destination, and in some embodiments includes reservation types and the importance of the reservation.
[0093] As Figure 12As emphasized, autonomous vehicles can communicate via various networks and with various devices and servers. In an embodiment, V2X vehicle A 1280 can communicate with V2X or another vehicle B 1290 with an enabled communication transceiver via link 1223 using V2X or other wireless or communication transceivers to, for example, perform vehicle-to-vehicle negotiation for lane change or for passing through an intersection in an embodiment, and exchange V2X capability data elements, such as vehicle status, position and capabilities, measurement data, and / or calculated status, and exchange other V2X vehicle status steps not covered in the V2X capability data elements. In an embodiment, vehicle A can also communicate with vehicle B via a network, such as via base station 1220 and / or access point 1230 or via an enabled communication roadside unit (RSU) 1225 (any of which can relay communication, information, and / or transform protocols for use by other vehicles such as vehicle B especially in embodiments where vehicle B cannot directly communicate with vehicle A1280 in a common protocol). In an embodiment, vehicle A1280 can also communicate with roadside unit 1225, which in various embodiments can be various roadside beacons, traffic and / or vehicle monitors, traffic control devices, and location beacons.
[0094] In an embodiment, roadside unit (RSU) 1225 can have a processor 1225A configured to operate a wireless transceiver 1225E to send and receive wireless messages from base station 1220 and / or access point 1230, such as basic safety messages (BSM) or cooperative awareness messages (CAM) or other V2X messages to and from vehicle A1280 and / or vehicle B 1290. For example, wireless transceiver 1225E can send and / or receive wireless messages using various protocols such as those for V2X communication with vehicles and / or using various WAN, WLAN, and / or PAN protocols for communication via a wireless communication network. In an embodiment, wireless transceiver 1225E can communicate via a wireless communication network by sending or receiving wireless signals from a wireless base transceiver subsystem (BTS), Node B, or evolved NodeB (eNodeB) or next-generation NodeB (gNodeB) over a wireless communication link. In an embodiment, wireless transceiver 1225E can include various combinations of WAN, WLAN, and / or PAN transceivers. In an embodiment, the local transceiver can also be a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceiver. The local transceiver, WAN wireless transceiver, and / or mobile wireless transceiver can include a WAN transceiver, an access point (AP), a femtocell, a home base station, a small cell base station, a home node B (HNB), or a home eNodeB (HeNB) or next-generation eNodeB (gNodeB) and can provide access to a wireless local area network (WLAN, e.g., IEEE 802.11 network), a wireless personal area network (PAN, e.g., Access to a network (e.g., a cellular network such as an LTE network or other wireless wide area network, such as the LTE network or other wireless wide area network discussed in the next paragraph). It should be understood that these are merely examples of networks that can communicate with the roadside unit (RSU) 1225 via a wireless link, and the claimed subject matter is not limited in this regard.
[0095] The RSU 1225 can receive location, status, and capability information from vehicle A 1280 and / or vehicle B 1290, such as speed, forward direction, location, stopping distance, priority or emergency status, and other vehicle-related information, and in some embodiments, can receive environmental information, such as road surface information / status, weather status, and camera information. The RSU 1225 can utilize the information received from vehicle A 1280 and / or vehicle B 1290, the environment, and roadside sensors 1225D via the wireless transceiver 1225E and network information and control messages from, for example, the traffic control and optimization server 1265 to coordinate and direct traffic flow and provide environmental, vehicle, safety, and announcement messages to vehicle A 1280 and vehicle B 1290.
[0096] The processor 1225A can be configured to operate the network interface 1225B, which in an embodiment can be connected to the network 1270 via a backhaul and which can be used in an embodiment to communicate and coordinate with various centralized servers such as the centralized traffic control and optimization server 1265 that monitors and optimizes traffic flow in an area such as within a city or a part of a city or in a certain region. The network interface 1225B can also be used for remote access to the roadside unit (RSU) 1225 for crowdsourcing of vehicle data, maintenance of the roadside unit (RSU) 1225, and / or coordination with other roadside units 1225 or other purposes. The roadside unit (RSU) 1225 can have a processor 1225A that is configured to operate the traffic control unit 1225C, which can be configured to process data received from vehicles such as vehicle A 1280 and vehicle B 1290, such as location data, stopping distance data, road condition data, identification data, and other information related to the status and location of nearby vehicles and the environment. The roadside unit (RSU) 1225 can have a processor 1225A that is configured to obtain data from the environmental and roadside sensors 1225D, which can include temperature, weather, cameras, pressure sensors, road sensors (e.g., for vehicle detection), accident detection, movement detection, speed detection, and other vehicle and environmental monitoring sensors.
[0097] In an embodiment, vehicle A1280 can also communicate with mobile device 1200 using short-range communication and personal networks (such as Bluetooth, WiFi, or Zigbee) or via V2X or other vehicle-related communication protocols, for example, to access a WAN and / or WiFi network and / or to obtain sensor and / or location measurements from mobile device 1200 in an embodiment. In an embodiment, vehicle A1280 can communicate with mobile device 1200 using a WAN-related protocol over a WAN network such as via WAN base station 1220 or using WiFi direct peer-to-peer or via a WiFi access point. Vehicle A1280 and / or vehicle B 1290 can use various communication protocols to communicate. In an embodiment, vehicle A 1280 and / or vehicle B 1290 can support various and multiple wireless communication modes such as, for example, using V2X, GSM, WCDMA, LTE, CDMA, HRPD, Wi-Fi, BT, WiMAX, Long Term Evolution (LTE), 5th Generation Wireless (5G) New Radio Access Technology (NR) communication protocols, etc.
[0098] In an embodiment, vehicle A can communicate over a WAN network using a WAN protocol via base station 1220 or communicate with a wireless LAN access point 1230 using a wireless LAN protocol such as WiFi. The vehicle can also support wireless communication using, for example, Wireless LAN (WLAN), a personal area network (PAN) such as Bluetooth TM or ZigBee, DSL, or packet cable.
[0099] In an embodiment, vehicle A 1280 and / or vehicle B 1290 can include one or more GNSS receivers, such as GNSS receiver 970, for receiving GNSS signals 1212 from GNSS satellites 1210, for position determination, time acquisition, and time maintenance. The GNSS receiver 970 or other receivers can be used alone or in combination to support various GNSS systems to receive signals from Beidou, Galileo, Glonass, and / or GPS, as well as various regional navigation systems such as QZSS and NavIC or IRNSS. Other wireless systems can be utilized, such as a beacon-dependent wireless system, which in one example is one or more roadside units (RSUs) 1225, one or more wireless LAN access points 1230, or one or more base stations 1220. Various GNSS signals 1212 can be combined with automotive sensors 940 and / or 945 to determine, for example, position, speed, and proximity to other vehicles between vehicle A1280 and vehicle B 1290.
[0100] In an embodiment, vehicle A and / or vehicle B may access GNSS measurements and / or positions determined at least in part using GNSS provided by a mobile device 1200, which in an embodiment will also have GNSS, WAN, WiFi, and other communication receivers and / or transceivers. In an embodiment, in a situation where the GNSS receiver 970 fails or provides a GNSS measurement and / or position less than a threshold level of positional accuracy, vehicle A 1280 and / or vehicle B 1290 may access GNSS measurements and / or positions determined at least in part using GNSS provided by a mobile device 1200 as a fallback.
[0101] In an embodiment, vehicle A 1280 and / or vehicle B 1290 may directly or indirectly (such as via a roadside unit) access various servers on a network, such as vehicle information server 1255, route server 1245, location server 1260, map server 1250, environmental data server 1240, and traffic control and optimization server 1265. The various servers including vehicle information server 1255, route server 1245, location server 1260, map server 1250, environmental data server 1240, and traffic control and optimization server 1265 include: at least one processor, which may include a general-purpose processor, DSP, dedicated processor, and various combinations thereof; a memory, which includes RAM, ROM, flash memory, hard disk drive, and virtual memory or various combinations thereof; and at least one network interface, which may include a physical link, such as a LAN cable, fiber optic, or other physical connection, a wireless link, such as a wide area network (WAN), wireless LAN (WLAN), personal area network, and short-range network connection (PAN), such as Bluetooth, Zigbee, and some 5G device-to-device communications and / or any combination thereof.
[0102] Vehicle information server 1255 may provide information describing various vehicles, such as may be used to make decisions about nearby cars, such as whether a vehicle is capable of stopping or accelerating in real time, whether a vehicle is driving autonomously, whether it is capable of autonomous driving, and / or whether it is capable of communicating. In an embodiment, vehicle information server 1255 may also provide information about vehicle size, shape, capabilities, identification, ownership, occupancy, and / or a determined location point (such as the location of a GNSS receiver) and the position of the vehicle boundary relative to the determined location point.
[0103] Route server 1245 may receive current location and destination information and provide route information, map data, alternative route data, and / or traffic and street condition data for a vehicle.
[0104] In an embodiment, the location server 1260 may provide location determination capabilities, transmitter signal acquisition assistance (such as GNSS satellite orbit prediction information, time information, approximate location information, and / or approximate time information), a transceiver almanac containing, for example, the identification and location of WiFi access points and base stations, and in some embodiments, provide additional information relative to a route, such as speed limits, traffic, and road conditions / construction status. The map server 1250 may provide map data, such as road locations, points of interest along the road, address locations along the road, road size, road speed limits, traffic conditions, and / or road conditions (wet, slippery, snow / ice, etc.), road status (open, construction, accident, etc.). In an embodiment, the environmental data server 1240 may provide weather and / or road-related information, traffic information, terrain information, and / or road quality and speed information, and / or other relevant environmental data. V
[0105] In an embodiment, Figure 12 the vehicles 1280 and 1290 and the mobile device 1200 in may communicate via the network 1270 through various network access points such as a wireless LAN access point 1230 or a wireless WAN base station 1220 on the network 1270. In some embodiments, Figure 12 the vehicles 1280 and 1290 and the mobile device 1200 in may also use various short-range communication mechanisms to communicate directly between devices, between vehicles, and between device-to-vehicle and vehicle-to-device, such as to communicate directly without passing through the network 1270 via Bluetooth, Zigbee, and the 5G New Radio standard.
[0106] As Figure 13A and Figure 13B shown, in an embodiment, a vehicle 1000 (e.g., a car, a truck, a motorcycle, and / or other motor vehicles) may exchange vehicle autonomy capabilities to achieve a desired lane change maneuver in a situation of a closer vehicle spacing. In Figure 13A and Figure 13BIn an embodiment, the self-driving vehicle E1300 changes lanes to merge between the vehicles on its right, moves from lane 3 to lane 2, and enters the gap between two autonomous vehicles A1305A and 1305B. The BSM (or CAM or other V2X) messages from the autonomous vehicles in lane 2 include data elements designating vehicle A as driving autonomously. The BSM (or CAM or other V2X) messages for the self-driving vehicle E (the vehicle planning to change lanes from lane 3 to lane 2) also include data elements designating vehicle E as driving autonomously. Vehicle E 1300 negotiates with vehicles A1305A and 1305B in lane 2 and executes the lane change. Since vehicle E 1300 and vehicles A1305A and 1305 know about each other's autonomy, a closer inter-vehicle spacing can be achieved compared to a situation where vehicle A in lane 2 is non-autonomous and / or unable to communicate its status and desired lane change information.
[0107] In Figure 14 In an embodiment, Figure 14 The autonomous vehicle E 1300 shown as autonomous vehicle (E) 1404 in Figure 14 The example message flow between the autonomous vehicle A1305A and 1305B shown as autonomous vehicle (A) 1402 in Figure 13A and Figure 13Bis shown by the lane change. In step 1406, autonomous vehicles A 1305A and 1305B send BSM / CAM messages containing data elements indicating the autonomous vehicle capabilities for vehicles A 1305A and 1305B. In step 1408, self-driving vehicle E 1300 sends a BSM / CAM message containing data elements indicating the autonomous vehicle capabilities for vehicle E 1300. In an embodiment, these messages may be broadcast or may be point-to-point. In step 1410, autonomous vehicles A 1305A and 1305B negotiate a lane change with self-driving vehicle E 1300 via BSM and / or CAM messages. In an embodiment, autonomous vehicles A 1305A and 1305B and self-driving vehicle E 1300 may negotiate timing, inter-vehicle spacing, and the event schedule involved such that the lane change can be safely completed. In an embodiment, self-driving vehicle E 1300 sends a request to the autonomous vehicle (A) corresponding to vehicles 1305A and 1305B of FIG. 13, thereby requesting a lane change for the destination position between autonomous vehicles A 1305A and 1305B. This request may be broadcast to nearby vehicles or may be sent point-to-point from self-driving vehicle (E) 1300 to autonomous vehicles 1305A and 1305B of FIG. 13. In an embodiment, autonomous vehicles A 1305A and 1305B may respond to self-driving vehicle (E) 1300 with an acknowledgement and acceptance or rejection of the request to increase the inter-vehicle spacing between autonomous vehicles A 1305A and 1305B. Autonomous vehicles A 1305A and 1305B may send messages to each other to negotiate whether vehicle 1305A accelerates or vehicle 1305B decelerates or some combination thereof. If either of autonomous vehicles A 1305A and 1305B is unable to increase the spacing or if one of the autonomous vehicles can enter a larger available space in front (1305A) or behind (1305B) it, then that vehicle may be selected or actively increase the spacing between autonomous vehicles A 1305A and 1305B while the other of the other pair of autonomous vehicles A 1305A and 1305B takes no other action. In an embodiment, once autonomous vehicles A 1305A and 1305B have reached the requested spacing, one or both of autonomous vehicles A 1305A and 1305B will send a message indicating that the required spacing has been reached to the requesting self-driving vehicle (E) 1300, thereby enabling self-driving vehicle (E) 1300 to move from its current lane into the space created between autonomous vehicles A 1305A and 1305B. If one of the vehicles in the target lane is non-autonomous, self-driving vehicle (E) may alternatively request space between a nearby pair of autonomous vehicles, or in an alternative, the autonomous vehicle in a pair of autonomous and non-autonomous vehicles may create the entire space for self-driving vehicle (E) to merge into it.In addition, if one of the two vehicles is non-autonomous, the autonomous vehicle can increase the spacing between that one vehicle and the non-autonomous vehicle to be greater than the other spacing allocated between two autonomous vehicles to provide an additional margin for a safe lane change.
[0108] In an embodiment, as Figure 15A and Figure 15B shown in, vehicle 1000 (e.g., car, truck, motorcycle, and / or other motor vehicle) can exchange vehicle autonomy messaging between autonomous vehicle E (1500) and non-autonomous vehicles (1510A, 1510B, 1510C) in a target lane to achieve a desired lane change maneuver, but with a larger vehicle spacing between autonomous vehicles. In Figure 15A and Figure 15B shown in, in an embodiment, vehicle E (1500) intends to change lanes to the left from lane 3 to lane 4 between two non-autonomous vehicles (1510A, 1510B). BSM (or CAM or other V2X) messages from non-autonomous vehicles in lane 4 include data elements designating vehicles 1510A and 1510B as driving non-autonomously. BSM (or CAM or other V2X) messages for self-driving vehicle E (1500) (the vehicle planning to change lanes from lane 3 to lane 4) include data elements designating vehicle E (1500) as driving autonomously. Vehicle E (1500) negotiates the lane change with vehicles in lane 4 and executes the lane change. Since vehicle E (1500) and vehicles 1510A and 1510B know each other that vehicles 1510A and 1510B are non-autonomous, a larger inter-vehicle lane spacing is utilized compared to the case where vehicles 1510A and 1510B in lane 4 are autonomous. If either of the non-autonomous vehicles (1510A, 1510B) is unable to respond to the lane change request of autonomous self-driving vehicle 1500, it can respond with an inability message (a rejection or other message indicating its inability to respond). If the other non-autonomous vehicle among non-autonomous vehicles (1510A, 1510B) is able to respond, it can create the entire gap without additional participation of the other non-autonomous vehicle among non-autonomous vehicles (1510A, 1510B). Otherwise, based on the request failure, autonomous self-driving vehicle 1300 can re-aim the lane merge to another space and / or another pair of vehicles.
[0109] In Figure 16 shown in, in an embodiment, an exemplary message flow between autonomous vehicle (E) 1604 and non-autonomous vehicle 1602 (e.g., Figure 15A and Figure 15B 1510A and 1510B of) is shown for the lane change shown in Figure 15A and Figure 15B shown in. In Figure 16 shown in, in an embodiment, autonomous vehicle E 1604 (e.g., asFigure 15A and Figure 15B shown in is the exemplary message flow between the autonomous vehicle (E) 1500 and the non - autonomous vehicle 1602 (e.g., 1510A and 1510B, as Figure 15A and Figure 15B shown in) is illustrated for Figure 15A and Figure 15B the lane change shown in the figure. In step 1606, the non - autonomous vehicle A 1602 sends BSM and / or CAM messages that contain data elements indicating the non - autonomous vehicle state or lack of autonomous vehicle capabilities for the non - autonomous vehicle 1602. In an embodiment, the message can be broadcast to nearby vehicles or sent point - to - point as a response to a request from a nearby vehicle or both. In step 1608, the autonomous vehicle (E) 1604 sends BSM / CAM messages that contain data elements indicating the autonomous vehicle capabilities for the autonomous vehicle (E) 1604. In an embodiment, these messages can be broadcast or can be point - to - point. In step 1610, the autonomous vehicle 1602 (e.g., Figure 15A and Figure 15B 1510A and 1510B) negotiates a lane change with the autonomous vehicle (E) 1604 via BSM and / or CAM messages. In an embodiment, the non - autonomous vehicle 1602 and the autonomous vehicle (E) 1604 can negotiate timing, inter - vehicle spacing, and the event schedule involved so that the lane change can be safely completed. In an embodiment, the autonomous vehicle (E) 1604 sends a request to the one associated with Figure 15A and Figure 15Bcorresponding non-autonomous vehicles 1602 to vehicles 1510A and 1510B, thereby requesting a lane change to a destination location between the two non-autonomous vehicles 1602. The request may be broadcast to nearby vehicles or sent point-to-point from the self-driving vehicle (E) 1604 to the non-autonomous vehicles 1602. In an embodiment, the non-autonomous vehicles 1602 may respond to the request with an acknowledgement and acceptance or rejection to request the self-driving vehicle (E) 1604 to increase the inter-vehicle spacing between the non-autonomous vehicles 1602. The non-autonomous vehicles 1602 may send messaging between each other to negotiate whether one non-autonomous vehicle accelerates or whether the other non-autonomous vehicle decelerates or some combination thereof. If the non-autonomous vehicles 1602 cannot increase the spacing (e.g., blocked by non-autonomous vehicles or other vehicles that are not capable of supporting an automatic lane change) or if one of the non-autonomous vehicles 1602 may enter a larger available space in front of or behind it, that vehicle may be selected or proactively increase the spacing between the non-autonomous vehicles 1602 without additional action by the other of the pair of non-autonomous vehicles 1602. In an embodiment, once the non-autonomous vehicles 1602 reach the requested spacing, one or both of the non-autonomous vehicles 1602 will send a message indicating that the desired spacing has been reached to the requesting self-driving vehicle (E) 1604, enabling the self-driving vehicle (E) 1604 to move from its current lane into the space created between the non-autonomous vehicles 1602. As an alternative, since the vehicles in the target lane are non-autonomous, the self-driving vehicle (E) may alternatively request space between a pair of nearby autonomous vehicles, or as another alternative, the autonomous vehicle in a pair of an autonomous and a non-autonomous vehicle may create the entire space for the self-driving vehicle (E) 1604 to merge into. Additionally, since the two vehicles in the target lane are non-autonomous, the autonomous vehicle requesting the lane change may request an increased spacing between the two non-autonomous vehicles prior to merging into its lane compared to the case where it would request spacing between two autonomous vehicles to provide an additional margin for a safe lane change.
[0110] As Figure 17 shown in an embodiment, vehicles 1000 (e.g., cars, trucks, motorcycles, and / or other motor vehicles) may exchange stopping distances for vehicle announcements to determine platooning or other inter-vehicle spacing. In an embodiment, the vehicle determines the stopping distance based on detected parameters such as vehicle speed, detected road / weather conditions, inherent braking ability, vehicle internal state (e.g., tire pressure), and vehicle driving state (autonomous or non-autonomous). In Figure 17 the example, V5 (1706) announces a larger stopping distance due to detected road conditions (water on the road or other road hazards such as ice, gravel, or sand on the road). There is platooning or other inter-vehicle spacing and a larger announced stopping distance due to one or more detected road conditions. Here, in Figure 17Among them, since the V5(1706) announcement has a large stopping distance due to water or other road hazards, the V4(1704) and V5(1706) can increase the inter-vehicle spacing between each other.
[0111] In Figure 18 Among them, in the embodiment, an exemplary message flow between the autonomous vehicles V1(1802), V2(1804), V3(1806), V4(1808) and V5(1810) is shown, and it has a stopping distance based on the vehicle state and the sensed environment. In step 1812, each of V1(1802) to V5(1810) uses BSM or CAM messaging to broadcast based on the corresponding vehicle state (e.g., tire tread, tire inflation, current weight) and environment (hazards on the road, such as water, ice, gravel or sand, road composition, weather, wind, and / or visibility distance). The vehicle will utilize the broadcast stopping distance of each nearby vehicle to negotiate platooning and / or other inter-vehicle spacing (i.e., platooning formation does not have to use this technology) using the stopping distance provided by BSM (or CAM or otherwise) in step 1814 if it can do so. If the vehicle is unable to perform messaging or otherwise does not support inter-vehicle spacing adjustment based on broadcast stopping distance-related measurements, adjacent vehicles can adjust around it to compensate. In Figure 18 Among them, each vehicle dynamically updates its BSM (or CAM) messaging step for the stopping distance based on the self-detected vehicle conditions, externally detected environment and / or road conditions, and externally received road conditions from other vehicles and / or infrastructure entities (such as the environmental data server 1240 and / or the map server 1250 and / or the roadside unit (RSU) 1225).
[0112] In Figure 19A and Figure 19B Among them, in the embodiment, the surrounding vehicles stop to allow the emergency vehicle to pass through the intersection. In Figure 19A and Figure 19BIn an embodiment, vehicles V1, V2, and V3 broadcast BSM (or other V2X, such as CAM messaging) messages with calculated stopping distances. The emergency (or other priority) vehicle V2 sends an intersection priority request to a roadside unit (RSU), such as a signal request message SRM. Based on the respective stopping distances provided by V1 and V3 (using the respective stopping distances from the intersection and the estimated distances, the RSU can determine whether V1 and V3 can safely stop before the intersection), the RSU grants V2 intersection entry (sends a signal status message, SSM) after determining that V1 and V3 can safely stop. The RSU then sends a modified intersection timing (e.g., a SPAT message). The RSU then sends a signal status message (SSM) to V1 and V3, thereby requesting a stop at the intersection. The emergency / priority vehicle V2 continues to travel through the intersection, while V1 and V3 stop at the intersection.
[0113] In Figure 20 In an embodiment, an exemplary message flow between vehicles approaching an intersection is shown, which includes messages with stopping distances. In an embodiment, vehicles V1, V2, and V3 send BSM messages using message steps, which contain the respective stopping distances of the vehicles based on the vehicle states and the sensed environment. In the case where V2 is an emergency vehicle, in an embodiment, the RSU will verify that vehicles V1 and V3 can safely stop before the intersection based on the stopping distances provided by V1 and V3. If V1 and V3 can stop, the RSU will grant V2 intersection entry based on the stopping distances provided by V1 and V3. The RSU will also update the intersection signal timing, for example using a SPAT message, so that the emergency vehicle V2 can continue to travel through the intersection without stopping. The RSU sends a signal status message (intersection entry message) to V2 to convey the grant of intersection entry to V2. Similarly, the RSU sends a signal status message denying intersection entry to V1 and V3, thereby requesting V1 and V3 to stop at the intersection. The emergency vehicle V2 then continues to travel through the intersection, while V1 and V3 stop at the intersection. In the case where all three vehicles are non-emergency vehicles, in an embodiment, the RSU can minimize the number of vehicles stopping at the intersection and allocate intersection entry in a way that maximizes traffic throughput (so here, V1 and V3 will be instructed / messaged to cross the intersection, and V2 will be instructed to stop, assuming that the stopping distance of V2 provided via BSM allows for a safe stop before the intersection).
[0114] In Figure 21A and Figure 21B In an embodiment, an emergency vehicle decelerates and / or stops before passing through an intersection to allow vehicles that may not be able to stop to cross the intersection. InFigure 21A and Figure 21B In, in an embodiment, vehicles V1, V2, V3 broadcast BSMs (or other V2X messaging) with calculated stopping distances; here, due to the water hazard and / or due to other factors such as vehicle speed, vehicle weight, and road surface conditions, the stopping distance of V1 is increased (it should be noted here that in the example, V1 can be a truck; however, V1 can also be a car or other vehicle type). The emergency (or other emergency) vehicle V2 sends an intersection priority request (such as, for example, a signal request message SRM) to the roadside unit (RSU). Based on the stopping distance provided by V1, the RSU determines that V1 cannot safely stop before the intersection and denies V2 intersection entry, sending a signal status message SSM such that V2 will decelerate or stop for the intersection to allow V1 to cross the intersection first. The RSU then sends a modified intersection timing (e.g., a SPAT message). Then, the RSU sends the SSM to V1, V3. V1 continues to travel through the intersection. The emergency / priority vehicle V2 and the vehicle V3 stop at the intersection. In an embodiment, if V3 can also safely continue to travel while V1 continues to travel through the intersection, then V1 and V3 can cross the intersection, being granted entry due to the broadcast stopping distance of V1. Once V1 has crossed the intersection or if V3 is also allowed to pass, once V1 and V3 have crossed the intersection, the RSU sends a signal status message indicating that the emergency vehicle V2 can cross the intersection.
[0115] In Figure 22 In, in an embodiment, an exemplary message flow between vehicles approaching an intersection is shown, which has messaging including stopping distances and further including messaging of vehicles with increased stopping distances due to sensed environmental conditions, the message flow reflecting Figure 21A and Figure 21B the messages involved in the scenario shown. Thus, in an embodiment, in step 2210, vehicles V1, V2, and V3 broadcast BSM messaging including respective stopping distance data elements based on vehicle state and sensed environmental data. As Figure 21A and Figure 21BAs shown, vehicle V1 determines environmental data indicating the presence of a wet / slippery road condition and thus broadcasts a longer stopping distance in a BSM message. In step 2212, emergency vehicle V2 sends a signal request message for intersection entry to a roadside unit (RSU). Based on the broadcast BSM stopping distance of V1, the roadside unit (RSU) 2208 will determine that vehicle V1 cannot safely stop before the intersection and the RSU will deny the intersection entry request of V2 based on the stopping distance provided by V1, and thus update the intersection signal timing via SPAT or other messages, thereby enabling vehicle V1, or in some embodiments, allowing vehicle V1 and V3 to cross the intersection if both can safely pass simultaneously. Thus, in step 2214, a signal status message will be sent from the RSU to vehicle V2, thereby denying intersection entry, causing vehicle V2 to subsequently stop at the intersection. Moreover, in step 2216, a signal status message will be sent from the RSU to vehicle V1, thereby granting intersection entry to vehicle V1 that will subsequently cross the intersection. In an embodiment, a signal status message or other message may be sent to vehicle V3, thereby denying intersection entry, which causes vehicle V3 to subsequently stop at the intersection while waiting for vehicle V1 and then waiting for vehicle V2 to cross the intersection; or, in an embodiment, the RSU may determine that V1 and V3 are traveling in the same direction or at least determine that their respective paths do not conflict (e.g., V3 and V1 travel straight through the intersection or turn right) and can cross the intersection simultaneously, in which case vehicle V3 may receive a signal status message or other message that allows vehicle V3 and vehicle V1 to enter the intersection simultaneously before allowing emergency vehicle V2 to enter the intersection.
[0116] Thus, once V1 crosses the intersection (or, in the case where both are allowed, both V1 and V3 cross the intersection), the RSU 2208 sends a new signal status message or other message granting intersection entry to V2, thereby instructing V2 to continue traveling through the intersection. Once vehicle V2 continues traveling through the intersection, then in the case where V3 was previously not allowed to pass through the intersection while V1 crossed the intersection, a signal status instruction may then be sent to vehicle V3, authorizing vehicle V3 to cross the intersection.
[0117] In Figure 23In an embodiment, the self-driving vehicle communicates with the first and second vehicles to request that the first and second vehicles provide a lane entry and a requested spacing to enable the self-driving vehicle to merge into its lane. In an embodiment, the requested spacing may take into account whether other vehicles are autonomous or non-autonomous (autonomous vehicle status) and the braking distances for various vehicles. For example, in an embodiment, if the vehicle in front of the self-driving vehicle can stop at a distance X and the self-driving vehicle can stop at a distance Y, where distance X is shorter than Y, the self-driving vehicle may request additional space between the self-driving vehicle and the vehicle in front of it (e.g., Y - X or more additional distance) to allow the self-driving vehicle to not be able to stop within distance X. Similarly, the vehicle behind the self-driving vehicle will negotiate for an appropriate spacing between the self-driving vehicle and the vehicle behind it. Thus, if the self-driving vehicle can stop at a distance X and the vehicle behind it can stop at a distance Y; if X > Y, the vehicle behind needs to allow for at least a distance of Y. However, if X < Y, the vehicle behind needs to allow for at least a distance of Y + (Y - X) between the two vehicles. It should be understood that the stopping distance is dynamic and can vary depending on many factors, which include vehicle weight, cargo weight, tire pressure, road surface type, road surface condition, weather, tire tread, brake wear, brake pressure, and other factors. Thus, in an embodiment, each of the vehicles will send a message (e.g., a broadcast message) that includes a basic safety message (BSM) or a cooperative awareness message (CAM), where the message includes identification data elements, autonomous vehicle status data elements, and / or braking distance data elements, which can be used to determine and request an appropriate spacing between vehicles and an appropriate spacing allowed when vehicles merge lanes. It should also be understood that other factors in addition to the stated factors may also affect the safe distance between vehicles and additional space between vehicles that takes these factors into account (such as vehicle decision latency, unforeseen obstacles, etc.) may be allocated.
[0118] In Figure 23 it, it should be understood that the message may be sent and received via the wireless transceiver 930 and the antenna 932, and may be directed and / or utilized via the processor 910 and / or the DSP 920 and / or data and instructions may be stored in the memory 960, as Figure 9As described. It should also be understood that various sensors 945, accelerometers, gyroscopes, and magnetometers 940, cameras 935, LIDAR 950, and / or system 955 and / or externally provided information received via wireless transceiver 930 or otherwise are used to determine braking distance and other data elements. It should further be understood that various controls, actions, and / or maneuvers and the analysis used to determine the controls, actions, and / or maneuvers can be guided or executed via processor 910 and / or DSP 920 using data and / or instructions in memory 960, and processor 910 and / or DSP 920 using data and / or instructions in memory 960 can interact with various systems 955 and / or power and drive system 975 and / or other systems, such as Figures 9 to 11 as described.
[0119] In step 2310, the self-driving vehicle receives a first message from a first vehicle, where the message includes an identification data element for the first vehicle, an autonomous vehicle status data element for the first vehicle, a braking distance data element for the first vehicle, or a combination thereof. Message passing between vehicles can be sent as a basic safety message (BSM) or a cooperative awareness message (CAM) or via other message protocols supported by wireless transceiver 930.
[0120] In an embodiment, the first and second vehicles are target vehicles that will be in front of or behind the self-driving vehicle after the self-driving vehicle changes lanes to insert between the first and second vehicles. In an embodiment, the self-driving vehicle determines the identification for the autonomous vehicle status (driving autonomously or manually) and / or braking distance required for the first and second vehicles. This identification enables direct negotiation between the self-driving vehicle and the first and second vehicles.
[0121] Braking distance information can be used to determine the minimum safe distance between the self-driving vehicle and the merged first and second vehicles. For example, the distance between vehicles can be determined such that a collision is avoided in the event of a sudden stop of the vehicle. In an embodiment, if the vehicle targeted below requires more stopping distance than the vehicle in front of it, an additional distance is added to the inter-vehicle spacing (e.g., an additional buffer of the longer stopping distance minus the shorter stopping distance) to avoid a collision during an emergency stop of the vehicle. Further assume that, in an embodiment, an autonomous vehicle will have a faster response time than a manually driven vehicle. Therefore, in an embodiment, a manually driven vehicle can add an additional buffer to its stopping distance to account for the additional response time required for a manual stop relative to an autonomous stop. In an embodiment, manually operated vehicles with automatic emergency braking enabled can also be differentiated such that the emergency braking is faster than that of a fully manually operated vehicle, where the braking distance may not increase or increase very little relative to the braking distance for a fully autonomous vehicle.
[0122] can be determined as described in the reference Figure 11 and / or as described below. The braking distance can utilize information from the autonomous vehicle's external sensors 1102, the autonomous vehicle's internal sensors 1104, the autonomous vehicle's capabilities 1106, the external V2X input 1108, and the autonomous vehicle's motion state 1110, which includes the current motion station, such as speed and forward direction, and the future desired motion and forward direction. In an embodiment, the autonomous vehicle's capabilities can be based on empirical test data (such as factory test data) for the make and model of the autonomous vehicle, or can be based on the measured performance data of the autonomous vehicle or can be based on a formula, such as being formulated by using one or more of the formulas for the braking distance specified herein. In an embodiment, the autonomous vehicle's capabilities can also be based on empirical test data, which is modified based on the current vehicle motion state 1110 and information from the autonomous vehicle's internal sensors 1104 and the autonomous vehicle's external sensors 1102. For example, in an embodiment, the make and model of an automobile can be tested with stock tires and tire inflation at various speeds to determine the stopping distances and stopping distance curves at various speeds based on the assumption of stock tires and standard road surfaces. In an embodiment, the stopping distance curve can be stored as a table, where the stopping distance for a given speed can be interpolated based on entries at higher speeds and entries at lower speeds. In an embodiment, each stopping distance can be fitted into an equation or otherwise associated with speed. This can be done in a table or in an equation, where the speed of the vehicle and in some embodiments other factors and / or measurements are input into the equation or table, and the corresponding estimated stopping distance is output from the equation or table. Another consideration can include the reaction time of the vehicle once a decision to stop is made and / or the human reaction time in the case of manually operating the vehicle. If reaction time is considered, the speed of the automobile multiplied by the reaction time is added to the estimated braking distance. The braking distance consists of the reaction time used to initiate braking multiplied by the speed, and this braking distance is added to the distance required to stop the vehicle's motion once braking is initiated. Generally, the distance required for an automobile to stop is related to the square of the speed. It is also related to the road grade, road surface condition, vehicle load / weight, and the condition and type of the brakes utilized. Because road conditions and other environmental factors are also involved, the braking distance can vary and may need to be adjusted for changes in the environment, such as ice or snow or water on the road. In an embodiment, the equation for the braking distance d B can be expressed as d B =(t R *v)+(v 2 / k*f R *f L *f B ), where t R is the reaction time, v is the speed, f R is a function of the road surface condition and grade, fL is a function of the vehicle load, f B is a function of the brake nominal performance and the current braking state (such as wear level), and k is a scaling factor, which is derived through empirical tests in some embodiments. k*f R *f L *f B is an estimate considering road friction, brake effectiveness, and mass. A simpler but perhaps less accurate estimate: f can also be used R 、f L and f B variations, where d B =(t R *v)+(v 2 / 2ug), where u is the coefficient of friction and g represents gravity.
[0123] In some embodiments, effects related to tire traction, tire inflation, or load, or other effects, may also have different degrees of influence at different speeds (i.e., may also have a non-linear influence), or in some embodiments, may be estimated using a linear model, or in some embodiments, are represented by a constant factor (e.g., a wet road factor relative to a dry road factor). The estimated stopping distance may be adjusted via direct input into the equation or via modification of the stopping distance output for various sensor inputs. For example, the stopping distance decreases as tire pressure decreases due to more contact with the road surface. However, drainage also decreases as tire pressure decreases due to tire deformation. Thus, in dry conditions, the stopping distance may increase due to over-inflated tires or decrease due to under-inflated tires. In an embodiment, for conservatism, the effect of increasing the stopping distance may be considered, but the effect of decreasing the stopping distance may be ignored or de-weighted / deprioritized relative to its effect. In wet conditions, under-inflated tires increase the risk of skidding, and in an embodiment, a tire pressure sensor may be used to detect an under-inflated condition where the pressure is less than a threshold pressure or a certain threshold less than the recommended pressure, which may be used to add additional distance to the stopping distance based on the increased likelihood of skidding or otherwise sliding on the road surface. Similarly, inputs from tire traction sensors such as an anti-lock braking sensor, a traction control sensor, and an all-wheel drive traction sensor may be used to detect a slippery surface and a loss of traction on the tire, and may trigger a preset increase in the braking distance or may increase the braking distance based on the measured degree of road slipperiness / lack of traction. In an embodiment, temperature may be used to modify the stopping distance. For example, warmer temperatures may affect the softness of the tire tread and increase traction on the road surface, while colder temperatures may harden the tire surface and reduce tire traction, thereby increasing the stopping distance in cold weather. Additionally, in the case of combining the detection of sub-freezing temperatures with moisture, precipitation, or high humidity, the road surface may be slippery or icy and the stopping distance may increase. In an embodiment, during standard driving conditions, the deceleration ability may be measured based on the speed reduction relative to a given applied braking force, and the braking distance may be re-determined and / or the equation or table may be re-calibrated and / or a compensation factor may be added or subtracted based on the currently measured braking performance. It should be understood that those skilled in the art may also consider other factors such as those provided by the autonomous vehicle external sensors 1102, the autonomous vehicle internal sensors 1104, the autonomous vehicle capabilities 1106, the external V2X input 1108, and the autonomous vehicle motion state 1110, and the present disclosure is not limited in this regard.
[0124] At step 2320, the self-driving vehicle receives a second message from the second vehicle, where the message includes an identification data element for the second vehicle, an autonomous vehicle status data element for the second vehicle, a braking distance data element for the second vehicle, or a combination thereof. In an embodiment, the identification step can be used as a reference for further communication directly with the second vehicle and for negotiation and requests between the self-driving vehicle and the second vehicle. Similarly, when creating space for the self-driving vehicle to merge into a lane, the first vehicle and the second vehicle can use the identification data element to negotiate and coordinate responses to requests for the self-driving vehicle's lane merge.
[0125] It should be understood that in some embodiments, the first message and the second message can be broadcast messages that can be received and utilized by nearby vehicles, while the request, confirmation, and negotiation messages can be sent directly between the affected vehicles. Other embodiments can utilize only broadcast messages or only point-to-point messages or various combinations thereof. In an embodiment, it is further realized that the first message and the second message can cover more than one message and / or multiple message steps and can be divided according to various protocols supported by the vehicles. In an embodiment, some or all of the point-to-point request, confirmation, and negotiation messages can be encrypted for privacy between the negotiating vehicles, where the negotiating, requesting, and confirming vehicles all have appropriate public and private keys. In an embodiment, such as in the case where one vehicle merges into the lane between two other vehicles, the communication can be shared by more than two vehicles to increase coordination between the affected vehicles, and in some embodiments, the communication is also shared with vehicles adjacent to the affected vehicles (e.g., in front and behind).
[0126] In step 2330, the self-driving vehicle determines a target space at least in part based on the size of the self-driving vehicle, the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status data element for the second vehicle, the braking distance data element for the first vehicle, or the braking distance data element for the second vehicle, or a combination thereof. In an embodiment, the determination of the target space can be further based on negotiation between the affected vehicles and can affect the size of the target space and the placement of the target space relative to the three vehicles. In this embodiment, for example, if the first vehicle has no obstacle in front of it and the second vehicle has another vehicle behind it, the first vehicle can accelerate to increase the spacing between the first vehicle and the second vehicle, and the self-driving vehicle can accelerate or decelerate appropriately to merge into the open target space between the first vehicle and the second vehicle.
[0127] In step 2340, the self-driving vehicle sends a third message to the first vehicle, thereby requesting the target space between the first vehicle and the second vehicle. As discussed above, in an embodiment, the third message may be point-to-point between the self-driving vehicle and the first vehicle, or in an embodiment, it may be broadcast and received by the first vehicle and the second vehicle, or it may be multicast to the first vehicle and the second vehicle. If the request for the target space for lane merging is broadcast or multicast to the first vehicle and the second vehicle simultaneously, the request may utilize a third message that identifies the first vehicle and the second vehicle as the message recipients for the request, thereby eliminating the need for a fourth message in step 2350.
[0128] In step 2350, the self-driving vehicle sends a fourth message to the second vehicle, thereby requesting the target space between the first vehicle and the second vehicle. As discussed above, in some embodiments, the third and fourth messages may be combined into a single request message that designates the first vehicle and the second vehicle as the recipients, in which case there is no need to send the fourth message.
[0129] In step 2360, the self-driving vehicle receives at least one response from either the fifth message from the first vehicle or the sixth message from the second vehicle or a combination thereof. In an embodiment, at least one response may be permission for the self-driving vehicle to merge between the first and the second vehicles. In an embodiment, at least one response may specify a timing and a relative position between the vehicle and the first vehicle and / or the second vehicle for the self-driving vehicle to initiate the merge. Additional messaging may be required to coordinate the movement and spacing between the self-driving vehicle and the first and / or second vehicles during and after the merge. In an embodiment, although the first and second vehicles may communicate before and during the merge, the first vehicle or the second vehicle or both the first and second vehicles may switch their communication with each other to the self-driving vehicle during or after completing the merge, such that each vehicle maintains communication with the vehicle immediately preceding or following it.
[0130] In step 2370, the self-driving vehicle maneuvers into the target space between the first vehicle and the second vehicle based on the at least one received response. In an embodiment, the self-driving vehicle will negotiate with the first vehicle and the second vehicle using appropriate messaging to determine the spacing between the self-driving vehicle and the first vehicle and between the self-driving vehicle and the second vehicle during and after the lane merge. In an embodiment, the self-driving vehicle may receive communication from the first vehicle or the second vehicle or from both vehicles regarding when to perform a lane change and may provide confirmation when the lane change is completed. Various conditions such as adverse weather conditions or adverse road conditions may be used to additionally affect the target speed or timing of the lane merge and / or the spacing between the target vehicle and the self-driving vehicle for performing the lane merge and / or the spacing between the self-driving vehicle and the first and / or second vehicle after the lane merge. In an embodiment, messaging from, for example, a lead vehicle of the first vehicle or also from other surrounding vehicles may also modify the timing of the merge due to lane obstacles such as potholes or due to slow traffic in the target lane, each of which may make it difficult to safely merge and / or may make it difficult for the first vehicle and the second vehicle to create the target space for the merge.
[0131] In Figure 24 an embodiment, the self-driving vehicle communicates with the vehicles in front of and behind it to request a safety spacing between the self-driving vehicle and the vehicle in front of the self-driving vehicle (referred to herein as the first vehicle for discussion purposes) and between the self-driving vehicle and the vehicle behind the self-driving vehicle (referred to herein as the second vehicle for discussion purposes). In an embodiment, the vehicles may be part of a platoon formation, where the vehicle will coordinate the spacing with the rest of the platoon, or in an embodiment, three vehicles may be traveling independently and only coordinate with each other. In an embodiment, the communication between the vehicles is similar between Figure 23 that which supports lane changes Figure 24 and that which supports inter-vehicle spacing Figure 23 where both activities require similar messaging, information, negotiation, and response from the current or targeted vehicles in front and behind, and generally refer to the discussion of Figure 24 and vice versa.
[0132] In Figure 24 an embodiment, it should be understood that messages may be sent and received via the wireless transceiver 930 and antenna 932 and may be directed and / or utilized via the processor 910 and / or the DSP 920 and / or data and instructions may be stored in the memory 960, as Figure 9as described. It should also be understood that various sensors 945, accelerometers, gyroscopes, and magnetometers 940, cameras 935, LIDAR 950, and / or systems 955 and / or externally provided information received via wireless transceiver 930 or otherwise are used to determine braking distance and other data elements. Further, it should be understood that various controls, actions, and / or maneuvers and the analysis used to determine the controls, actions, and / or maneuvers may be guided or executed by processor 910 and / or DSP 920 using data and / or instructions in memory 960, and processor 910 and / or DSP 920 using data and / or instructions in memory 960 may interact with various systems 955 and / or power and drive systems 975 and / or other systems, such as Figures 9 to 11 as described.
[0133] In Figure 24 it should be understood that in some embodiments, the first and second messages may be broadcast messages that can be received and utilized by nearby vehicles, while the request, confirmation, and negotiation messages may be sent directly between the affected vehicles. For example, the third and fourth messages may be point-to-point messages from the self-driving vehicle to the first vehicle and to the second vehicle, respectively. Other embodiments may utilize only broadcast messages or only point-to-point messages or various combinations thereof. In an embodiment, it is further recognized that the first and second messages may encompass more than one message and / or multiple message steps and may be divided according to various protocols supported by the vehicle. In an embodiment, some or all of the point-to-point request, confirmation, and negotiation messages (such as Figure 24 the third and fourth messages) may be encrypted for negotiating privacy and / or security between the negotiating vehicles, where the negotiating, requesting, and confirming vehicles all have appropriate public and private keys. In an embodiment, such as in the case where one vehicle merges into a lane between two other vehicles or in the case where one vehicle modifies the spacing in front of and behind it, the communication may be shared by more than two vehicles to increase coordination between the affected vehicles, and in some embodiments, the communication is also shared with vehicles adjacent to the affected vehicles (e.g., in front and behind). In an embodiment, the messaging between vehicles may be sent as a basic safety message (BSM) or a cooperative awareness message (CAM) or via other message protocols supported by wireless transceiver 930.
[0134] In step 2410, the self-driving vehicle receives a first message from the first vehicle, where the first message includes identification data elements for the first vehicle and autonomous vehicle status data elements for the first vehicle or braking distance data elements for the first vehicle or a combination thereof. As in Figure 23, Message passing between vehicles can be sent as a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM) or via other message protocols supported by the wireless transceiver 930. In an embodiment, the message can be broadcast, multicast, or point-to-point or a combination thereof. In an embodiment, information and / or status messages such as the first message and the second message can be implemented as a broadcast message or a point-to-point message to adjacent vehicles or as a multicast message to adjacent vehicles. Request, confirmation, negotiation, and response messages can be point-to-point between the affected parties or can be broadcast or multicast with the name of the target vehicle; for example, here, the third message and the fourth message can be point-to-point between the autonomous vehicle and the first vehicle and between the autonomous vehicle and the second vehicle, respectively. As discussed above regarding Figure 23 The derivation of the braking distance of a vehicle and the discussion of the relationship between the braking distance and various conditions and inputs and with the capabilities of autonomous vehicles were discussed.
[0135] At step 2420, the autonomous vehicle receives a second message from the second vehicle, where the second message includes an identification data element for the second vehicle and an autonomous vehicle status data element for the second vehicle or a braking distance data element for the second vehicle or a combination thereof. The second message can be sent as a broadcast or multicast message for use by neighboring vehicles or can be sent point-to-point to neighboring vehicles.
[0136] At step 2430, the autonomous vehicle determines a first target space between the autonomous vehicle and the first vehicle based on the autonomous vehicle status data element for the first vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the first vehicle, or the braking distance of the autonomous vehicle or a combination thereof. It should be understood that other factors can also be considered, such as the road surface, water on the road, weather conditions, tire pressure, surrounding traffic, and road hazards. It should be understood that this list is not comprehensive, and further discussion can be found by referring to Figure 23 and Figure 11 The discussion. In some embodiments, the determination of the first target space can be performed in the autonomous vehicle or in the first vehicle or collaboratively between the two vehicles.
[0137] At step 2440, a second target space between the autonomous vehicle and the second vehicle is determined based on the autonomous vehicle status data element for the second vehicle, the autonomous vehicle status of the autonomous vehicle, the braking distance data element for the second vehicle, or the braking distance of the autonomous vehicle or a combination thereof. As in step 2430, it should be understood that other factors can also be considered, such as the road surface, water on the road, weather conditions, tire pressure, surrounding traffic, and road hazards. It should be understood that this list is not comprehensive, and further discussion can be found by referring to Figure 23 and Figure 11The discussion of [find further discussion]. In some embodiments, the determination of the first and second target spaces can be performed in the autonomous vehicle or in the first vehicle or collaboratively between two vehicles.
[0138] In step 2450, the autonomous vehicle sends a third message to the first vehicle, thereby requesting the first target space between the first vehicle and the autonomous vehicle. However, it should be realized that adjacent vehicles can initiate the target space check and modification of the inter-vehicle space, or both can initiate the target space check and modification collaboratively. In terms of intent and exchanged content, Figure 24 Step 2450 is similar to Figure 23 Step 2340.
[0139] In step 2460, the autonomous vehicle sends a fourth message to the second vehicle, thereby requesting the second target space between the first vehicle and the second vehicle. In terms of intent and exchanged content, Figure 24 Step 2460 is similar to Figure 23 Step 2350.
[0140] In step 2470, the autonomous vehicle receives at least one response from the fifth message of the first vehicle or the sixth message of the second vehicle or a combination thereof. In an embodiment, at least one response will grant permission for the autonomous vehicle to adjust its position to create and / or coordinate the first target space between the first vehicle and the autonomous vehicle or the second target space between the first and second vehicles or a combination thereof. Additional messaging may be required to coordinate the movement and spacing between the autonomous vehicle and the first and / or second vehicles.
[0141] In step 2480, based on the received at least one response, the autonomous vehicle maneuvers as needed to manage the first target space between the autonomous vehicle and the first vehicle and the second target space between the autonomous vehicle and the second vehicle.
[0142] In Figure 25In an embodiment, the self-driving vehicle interacts with a roadside unit (RSU) that controls access to an intersection to request and receive permission to enter the intersection. In an embodiment, if the determined braking distance of the self-driving vehicle is greater than the distance between the self-driving vehicle and the approaching intersection (i.e., given the determined braking distance, the distance between the self-driving vehicle and the intersection is not sufficient for the self-driving vehicle to stop before the intersection), the RSU may grant the self-driving vehicle access to the intersection in accordance with a priority to other vehicles that can safely stop before the intersection. This may include a priority over other vehicles that would otherwise have a greater priority than the self-driving vehicle (such as emergency vehicles (police cars, fire trucks, ambulances, etc.)). If the determined braking distance of the self-driving vehicle is less than the distance between the self-driving vehicle and the approaching intersection (i.e., given the determined braking distance, the distance between the self-driving vehicle and the intersection is sufficient for the self-driving vehicle to stop before the intersection), the RSU may request the self-driving vehicle to stop before the intersection (i.e., the RSU does not grant the self-driving vehicle access to the intersection, but instead requests the self-driving vehicle to stop), so that the RSU may grant access to the intersection to vehicles that have a greater priority than the self-driving vehicle (e.g., emergency vehicles such as police cars, fire trucks, ambulances, etc.) and are closer to the intersection or cannot stop before entering the intersection or a combination thereof).
[0143] In Figure 25 it should be understood that messages may be sent and received via the wireless transceiver 930 and the antenna 932, and may be directed and / or utilized via the processor 910 and / or the DSP 920 and / or store data and instructions in the memory 960, as Figure 9 described in. It should also be understood that the various sensors 945, accelerometers, gyroscopes, and magnetometers 940, cameras 935, LIDAR 950, and / or systems 955 and / or externally provided information received via the wireless transceiver 930 or otherwise are used to determine the braking distance and other data elements. Further, it should be understood that the various controls, actions, and / or maneuvers and the analysis for determining the controls, actions, and / or maneuvers may be directed or executed via the processor 910 and / or the DSP 920 using the data and / or instructions in the memory 960, and the processor 910 and / or the DSP 920 using the data and / or instructions in the memory 960 may interact with the various systems 955 and / or the power and drive system 975 and / or other systems, as Figures 9 to 11 described in.
[0144] In Figure 25In an embodiment, the RSU may also provide information to the autonomous vehicle via peer-to-peer transmission or via local wireless broadcast, such as traffic information, road obstacle information, weather information, road surface information, pedestrian warnings, and / or other information related to the environment near the RSU. The RSU may also have non-vehicle inputs, such as radar, LIDAR, and camera inputs, that it can use to independently check traffic flow and direction, weather conditions, and road conditions (black ice, wet, etc.). The autonomous vehicle may consider the information provided by the RSU to determine data elements. For example, when determining the braking distance for an autonomous vehicle, the autonomous vehicle may consider weather, road surface, and other conditions that can be received from the RSU via a wireless message as data elements and affect the braking performance of the autonomous vehicle.
[0145] In step 2510, the autonomous vehicle determines its braking based on information from external sensors of the autonomous vehicle, internal sensors of the autonomous vehicle, the capabilities of the autonomous vehicle, or external V2X inputs, or a combination thereof. The braking distance may be determined as previously discussed with respect to Figure 23 For example, an initial value of the braking distance may be based on a lookup table of braking distances that is based on speed. For speed values between table entries, the braking distance may be interpolated. For example, if you have a lower speed V1 associated with a braking distance B1 and a higher speed V2 associated with a braking distance B2 and a speed V3 is between V2 and V1 such that V2 > V3 > V1, then B3 (the braking distance associated with speed V3) may be expressed as (V3 - V1) / (V2 - V1)*(B2 – B1)+B1. In other embodiments, speed and braking data having a non-linear relationship may be fit to a curve. It is noted that the stopping distance increases at a faster rate as the speed increases, and thus, in an embodiment, the speed and braking data may be plotted as a non-linear equation or it may be conservatively simplified to a linear equation that may result in an excessive braking distance at lower speeds in an embodiment. Additionally, the initial speed prediction may be modified to account for other factors, such as excessive vehicle weight, road surface, weather conditions (snow or ice on the road). In an embodiment, road or weather conditions may be addressed by modifying the initial braking estimate to add additional braking distance to account for weather, road irregularities, loose road surfaces (gravel, dust, or sand), ice or water on the road, and other factors that will decelerate braking. In an embodiment, a predetermined amount may be added to the stopping distance based on each condition, such as adding a margin to the estimate based on conservative empirical data. In an embodiment, the table or curve may be modified, or there may be different tables or curves, to account for degraded stopping conditions. In an embodiment, when modifying the amount of additional braking distance added to the initial braking distance (i.e., the braking distance for nominal conditions), measurements of wheel slip (such as traction control metrics), all-wheel drive anti-lock braking measurements of wheel slip, and / or the adhesion friction coefficient (adhesion between the road and the tire) may be used and / or considered.
[0146] In step 2520, the self-driving vehicle sends a first message, where the message includes an identification data element for the self-driving vehicle or vehicle type or vehicle priority or a combination thereof and a braking distance data element for the self-driving vehicle. In some embodiments, the vehicle type may specify, in non-limiting examples, whether the vehicle is a passenger car, a transport truck, an emergency vehicle, or other vehicle types. In some embodiments, the vehicle priority may include an indication of priority, such as whether the vehicle is in an emergency state, in a time-critical situation, in a moderately time-sensitive situation, or in a non-time-sensitive situation. In some embodiments, the vehicle priority may include an indication of a financial transfer, where the highest bidder may obtain the intersection entry priority over the lower bidder. In some embodiments, the vehicle status may include a numerical value or an ordered sequence representing relative priority (such as 1 to 5 or A to F). In some embodiments, the self-driving vehicle may also send an autonomy data element indicating whether the vehicle is being operated autonomously, such that response time or other factors related to autonomous operation can be considered. In some embodiments, the self-driving vehicle may send location information and / or speed and heading information. In some embodiments, the self-driving vehicle may include other relevant data elements in the message, such as a slippery road indicator and / or measurements of road / tyre slip and / or adhesion. In some embodiments, the self-driving vehicle message may include data elements for indicating surrounding traffic (such as whether there are vehicles in front of, behind, and / or to the sides of the self-driving vehicle). In some embodiments, the self-driving vehicle message may include an emergency, status, or priority flag, which may be used to increase the priority of the self-driving vehicle for intersection entry. In some embodiments, the self-driving vehicle message may include observation data and / or data received from adjacent vehicles, such as data regarding the status and / or emergency state of adjacent vehicles. The message may be sent directly to the RSU via, for example, a point-to-point message, or the message may be broadcast together with data elements corresponding to the identification data for the self-driving vehicle and the braking distance data for the self-driving vehicle. As Figure 23 , the message passing between the self-driving vehicle and the RSU may be sent as a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM) or via other message protocols supported by the wireless transceiver 930. In an embodiment, the message may be broadcast, multicast, or point-to-point or a combination thereof. In an embodiment, the information and / or status message may be implemented as a broadcast message or a point-to-point message to adjacent vehicles or as a multicast message to adjacent vehicles and / or roadside units. Request, confirmation, negotiation, and response messages may be point-to-point between the affected parties or may be broadcast or multicast together with the name of the target vehicle. The above regarding Figure 23 also discusses the derivation of the braking distance of the vehicle and the discussion of the relationship between the braking distance and various conditions and inputs and with the capabilities of autonomous vehicles.
[0147] In an embodiment, a roadside unit (RSU) may automatically assume that a vehicle approaching an intersection (such as an autonomous vehicle) requests intersection entry. In an embodiment, an autonomous vehicle may send a message requesting intersection entry to the RSU. In some embodiments, the RSU may assume that a vehicle approaching an intersection requests intersection entry and thus monitors the distance, speed, stopping distance, priority, and / or other factors of the approaching vehicle when determining the order of priorities to grant intersection entry.
[0148] In step 2530, the self-driving vehicle receives a second message from a roadside unit (RSU) at least partially based on the braking distance for the self-driving vehicle, which includes one or more instructions regarding the intersection entry of the self-driving vehicle. In an embodiment, the second message may include an instruction to grant or deny permission to enter the intersection, where the permission is at least partially based on the braking distance for the self-driving vehicle. In an embodiment, the second message may specify an approach speed to the intersection, which in an embodiment may be associated with the granting of permission to enter the intersection. In an embodiment, the approach speed may be determined such that other vehicles cross the intersection before the self-driving vehicle crosses the intersection. In an embodiment, the approach speed may be determined to maximize the traffic flow through the intersection. In an embodiment, the second message may be a broadcast signal status message. In an embodiment, the second message may be a point-to-point message. In an embodiment, if the self-driving vehicle's stopping distance exceeds the distance between the self-driving vehicle and the intersection, the RSU may grant the self-driving vehicle intersection entry and / or increased priority for intersection entry. In an embodiment, if the self-driving vehicle's stopping distance is less than the distance between the self-driving vehicle and the intersection (i.e., the self-driving vehicle is able to stop or at least decelerate before the intersection) and a higher-priority vehicle requests entry into the intersection, or if a vehicle closer to or waiting at the intersection requests entry into the intersection, the RSU may deny the self-driving vehicle entry into the intersection and instead request the self-driving vehicle to stop at the intersection while providing intersection entry to other vehicles. In an embodiment, if the self-driving vehicle's stopping distance is less than the distance between the self-driving vehicle and the intersection (i.e., the self-driving vehicle is able to stop or at least decelerate before the intersection) and other vehicle types request entry into the intersection, especially if a public policy or other policy indicates that a particular vehicle type is more favored than other vehicle types, the RSU may deny the self-driving vehicle entry into the intersection and instead request the self-driving vehicle to stop at the intersection or decelerate its approach while providing intersection entry to other vehicles of other types. For example, a public policy may favor public transportation vehicles such as buses and trains or larger vehicles such as larger trucks that use more energy when starting and stopping for transportation with the fewest stops; under this policy, public transportation vehicles and / or larger vehicles may have priority over passenger cars to enter the intersection. Similarly, high-occupancy vehicle types (or states) may have priority over low-occupancy vehicle types (or states). In an embodiment, the second message may be a broadcast signal status message from the RSU or the second message may be a point-to-point message from the RSU to the self-driving vehicle that grants or denies the self-driving vehicle intersection entry.
[0149] In step 2540, the self-driving vehicle can control the entry of the self-driving vehicle into the intersection in response to one or more instructions received from the RSU. In an embodiment, based on the second message, the self-driving vehicle can receive in the second message an instruction to enter the intersection or stop before the intersection to wait for the RSU to grant permission to enter the intersection. In an embodiment, the second message can include an instruction from the RSU to stop or continue moving for the self-driving vehicle, and can further include a request to modify the vehicle speed when the self-driving vehicle approaches the intersection. In an embodiment, the self-driving vehicle can receive from the RSU an instruction to decelerate or otherwise modify its speed (instead of stopping) before the intersection to allow other vehicles to cross the intersection before the self-driving vehicle reaches the intersection. In an embodiment, the self-driving vehicle can receive from the RSU an instruction to accelerate to cross the intersection before other vehicles. In an embodiment, the RSU can send the target approach speed to the intersection to the self-driving vehicle, such that the self-driving vehicle can approach the intersection at a speed slower than or faster than the current speed of the self-driving vehicle. In an embodiment, the self-driving vehicle can stop at the line dividing the intersection to wait for permission to enter the intersection.
[0150] In various embodiments, the self-driving vehicle can be illustrated by vehicle 1000 (e.g., as shown in Figures 9 to 11 ), and may be capable of performing position determination, navigation, autonomous driving, object detection, vehicle-to-vehicle communication, and / or other techniques for autonomous and / or semi-autonomous vehicles. In the various embodiments above, the terms "vehicle" and "self-driving vehicle" may be used interchangeably, where the systems within the self-driving vehicle may be referred to, for example, as vehicle systems or self-driving vehicle systems. For example, the terms "vehicle interior sensors" and "vehicle exterior sensors" refer to systems on the self-driving vehicle. The self-driving vehicle can be autonomous or can have an autonomous mode and a manual mode, or can have semi-autonomous features, such as automated lane control (e.g., where the self-driving vehicle is able to automatically stay in a lane or request to change lanes / merge into another lane or is able to automatically stop or automatically avoid road obstacles), but can otherwise be driven manually.
[0151] In various embodiments, and as discussed above, vehicle 1000 can utilize positioning techniques in combination with a brake pad and brake status monitoring system to estimate the braking distance (and / or in an embodiment, the braking effectiveness at different speeds), which can be estimated at multiple speeds (as can be measured by a positioning system and / or a speedometer, wheel monitor, etc.). The braking distance and / or performance relative to speed can be used to create a table of braking distances based on speed and / or equations suitable for braking data at different speeds, which can be used to estimate the braking distance. The braking distance can be regularly and periodically updated based on changing input parameters including changes in speed and position.
[0152] In various embodiments and as discussed above, vehicle 1000 may utilize a positioning system to determine a location that may be communicated to adjacent and / or nearby vehicles in a location data element. Vehicle 1000 may use the location to determine vehicle movement (e.g., when to merge lanes), or to determine a spacing between vehicles. Vehicle 1000 may exchange location information with adjacent or nearby vehicles to negotiate and coordinate movements such as lane changes and to adjust the spacing between vehicles.
[0153] In various embodiments, and as discussed above, vehicle 1000 (e.g., vehicle A1280 and vehicle B 1290) can have circuitry and processing resources that are capable of obtaining position-related measurements (e.g., for signals received from GPS, GNSS, or other satellite positioning system (SPS) satellites 1210, WAN wireless transceiver 1220, or WLAN or PAN local transceivers 1230 and potentially calculating a fixed or estimated position of vehicle 1000 based on these position-related measurements). In the presently shown example, the position-related measurements obtained by vehicle 1000 can include measurements of signals (1212) received from satellites (such as GPS, GLONASS, Galileo, or Beidou) that are part of SPS or global navigation satellite system (GNSS) (1210), and / or can include measurements of signals (such as 1222 and / or 1232) received from ground transmitters fixed at known locations (e.g., such as WAN wireless transceiver 1220). Vehicle 1000 or position server 1260 can then use any of several positioning methods based on these position-related measurements to obtain a position estimate for vehicle 1000, such positioning methods being, for example, GNSS, assisted GNSS (A-GNSS), advanced forward link trilateration (AFLT), observed time difference of arrival (OTDOA), or enhanced cell ID (E-CID), network triangulation, received signal strength indication (RSSI), or combinations thereof. In some of these techniques (e.g., A-GNSS, AFLT, and OTDOA, RSSI), pseudo-ranges, distances, or timing differences can be measured at vehicle 1000 relative to three or more than three ground transmitters at known locations or relative to four or more than four satellites with accurately known orbital data or combinations thereof, at least partially based on pilot, positioning reference signals (PRS), or other positioning-related signals transmitted by transmitters or satellites and received at vehicle 1000. The server can provide positioning assistance data to vehicle 1000, the positioning assistance data including, for example, information about the signals to be measured (e.g., signal timing and / or signal strength), the positions and identifiers of ground transmitters, and / or signal, timing, and orbital information for GNSS satellites to facilitate positioning techniques such as A-GNSS, AFLT, OTDOA, and E-CID. For example, position server 1260 can include an almanac indicating the positions and identifiers of wireless transceivers and / or local transceivers in one or more specific areas (such as a particular location), and can provide information describing signals transmitted by cellular base stations or APs or mobile ground transceivers, such as, transmit power and signal timing.In the case of E-CID, vehicle 1000 may obtain a measurement of the signal strength of signals received from WAN wireless transceiver 1220 and / or wireless local area network (WLAN) or PAN local transceiver 1230 and / or may obtain the round-trip signal propagation time (RTT) between vehicle 1000 and WAN wireless transceiver 1220 or wireless local transceiver 1230. Vehicle 1000 may use these measurements together with auxiliary data received from location server 1260 (such as terrestrial almanac data or GNSS satellite data, such as GNSS almanac and / or GNSS ephemeris information) to determine the location of vehicle 1000 or may transmit the measurements to location server 1260 to perform the same determination.
[0154] In various embodiments, the location may be determined in various ways as described above. For example, in an embodiment, vehicle 1000 may utilize GNSS satellite signal measurements, terrestrial transmitter signal measurements, or some combination thereof to determine its location. In an embodiment, vehicle 1000 may utilize LIDAR, radar, GNSS, sensors, and various combinations thereof to determine its location. In an embodiment, vehicle 1000 may use an accelerometer and / or gyroscope and various sensors to determine its location (wheel tick, steering direction, etc.) to determine the distance and direction traveled from the last determined location via dead reckoning. In an embodiment, vehicle 1000 may use a combination of signals and sensors to determine its location; for example, the location may be determined using various signal measurements from GNSS and terrestrial transmitters and then updated using dead reckoning. Various signal measurements from the determined location may be taken from visible transmitters to obtain an indication of the distance of the transmitter from the determined location. The distance indication may include signal strength or round-trip time or time of arrival or other distance estimation methods. New signal measurements may be made at the new determined location. By combining the indications of the distance to any given transmitter taken from multiple locations, whether through one device or through multiple devices, the location of the transmitter (such as WAN wireless transceiver 1220 or WLAN or PAN local transceiver 1230) may be determined. The location of the transmitter may be determined on vehicle 1000 or on a crowdsourcing server or on location server 1260 or other network-based server.
[0155] A vehicle (e.g., Figure 2The vehicles 1000 therein, for example, vehicle A 1280 and vehicle B 1290) may be referred to as devices, automobiles, trucks, motorcycles, flying devices (such as airplanes or drones), wireless devices, mobile terminals, terminals, mobile stations (MS), user equipment (UE), SUPL-enabled terminals (SET). Generally, although not necessary, vehicles may support wireless communication such as using V2X, GSM, WCDMA, LTE, CDMA, HRPD, Wi-Fi, BT, WiMAX, Long Term Evolution (LTE), 5th Generation Wireless (5G) or New Radio Access Technology (NR), V2X communication protocols, etc. Vehicles may also support wireless communication using, for example, Wireless LAN (WLAN), personal area networks (PAN) such as Bluetooth TM or ZigBee, DSL or packet cable. In an embodiment, the vehicle may support the transmission of basic safety messages (BSM) including various data elements (such as data elements depicting that the corresponding vehicle is being autonomously driven). In an embodiment, the vehicle may support the transmission of ETSI cooperative awareness messages (CAM), which, for example, in an embodiment include various data elements, such as data elements depicting that the corresponding vehicle is being autonomously driven.
[0156] The estimation of the location of a vehicle (e.g., vehicle 1000) may be referred to as location, location estimation, position lock, lock, position, position estimation or position lock, and may be geodetic, thus providing the vehicle with position coordinates (e.g., latitude and longitude), which may or may not include an elevation component (e.g., altitude, surface height or above-ground height or above-ground height or below-ground height). Optionally, the location of the vehicle may be expressed as an urban location (e.g., expressed as a postal address or the name of a point or small area (such as a specific room or floor) in a building). The location of the vehicle may also be expressed as an area or space (defined geographically or in an urban form) in which the vehicle is expected to be located with a certain probability or confidence level (e.g., 67% or 95%). The location of the vehicle may also be a relative location, which includes, for example, distance and direction or relative X, Y (and Z) coordinates defined relative to an origin at a known location, and the relative location is defined geographically or in urban terms or with reference to a point, area or space indicated on a map, floor plan or building plan. In the descriptions contained herein, unless otherwise indicated, the use of the term location may include any of these variations.
[0157] Throughout the specification, references to "an example", "examples", "certain examples", "in an embodiment", or "exemplary embodiments" mean that a particular feature, structure, or characteristic described in connection with the feature and / or example can be included in at least one feature and / or example of the claimed subject matter. Thus, the phrases "in one example", "examples", "in certain examples", or "in certain embodiments", or "in an embodiment", or other similar phrases that appear throughout the specification do not necessarily all refer to the same feature, example, and / or limitation. Further, a particular feature, structure, or characteristic can be combined or modified in one or more examples and / or features and in various embodiments. The specified embodiments are not intended to be limiting with respect to embodiments that can vary in details; those skilled in the art will recognize that other unspecified embodiments can also be used in conjunction with or to modify the described embodiments.
[0158] Some portions of the detailed descriptions included herein are presented in terms of algorithms or symbolic representations of operations on binary digital signals stored within a memory of a particular apparatus or a special purpose computing device or platform. In the context of this particular specification, once a term such as a particular apparatus is programmed to perform particular operations in accordance with instructions from program software, it includes a general purpose computer. The algorithmic descriptions or symbolic representations are examples of techniques used by ordinary artisans in the signal processing or related arts to convey the substance of their work to others skilled in the art. An algorithm is herein, and generally, considered to be a self-consistent sequence of operations or the like that leads to a desired result. In this context, an operation or process involves physical manipulation of physical quantities. Usually, though not necessarily, such quantities can take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It has proven convenient at times, principally for reasons of generality, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, etc. However, it should be understood that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, it will be apparent from the discussion herein that throughout the specification, discussions using terms such as "processing", "computing", "calculating", "determining", etc., refer to the actions or processes of a particular apparatus, such as a special purpose computer, a special purpose computing device, or similar special purpose electronic computing device. Thus, in the context of this specification, a special purpose computer or similar special purpose electronic computing device is capable of manipulating or transforming signals that are typically represented as physical electronic or magnetic quantities within a memory, a register, or other information storage device, a transmitting device, or a display device of the special purpose computer or similar special purpose electronic computing device.
[0159] The wireless communication technologies described herein can be combined with various wireless communication networks, such as wireless wide area networks (“WANs”), wireless local area networks (“WLANs”), wireless personal area networks (PANs), and so on. The terms “network” and “system” may be used interchangeably herein. A WAN can be a code division multiple access (“CDMA”) network, a time division multiple access (“TDMA”) network, a frequency division multiple access (“FDMA”) network, an orthogonal frequency division multiple access (“OFDMA”) network, a single carrier frequency division multiple access (“SC-FDMA”) network, Long Term Evolution (“LTE”), Fifth Generation (“5G”), or any combination of the above networks, and so on. A CDMA network can implement one or more radio access technologies (“RATs”), such as cdma2000, Wideband-CDMA (“W-CDMA”), to name just a few radio technologies. Here, cdma2000 can include technologies implemented according to the IS-95, IS-2000, and IS-856 standards. A TDMA network can implement the Global System for Mobile Communications (“GSM”), Digital Advanced Mobile Phone System (“D-AMBP”), or some other RAT. GSM and W-CDMA are described in the documents of an alliance called the “3rd Generation Partnership Project” (“3GPP”). CDMA2000 is described in the documents of an alliance called the “3rd Generation Partnership Project 2” (“3GPP2”). The 3GPP and 3GPP2 documents are publicly available. On the one hand, 4G Long Term Evolution (“LTE”) communication networks can also be implemented in accordance with the claimed subject matter. A WLAN can include IEEE802.11x networks, and a PAN can include Bluetooth networks, IEEE 802.15x, which includes, for example, Zigbee networks. The wireless communication implementations described herein can also be used in combination with any combination of WANs, WLANs, or PANs.
[0160] On the other hand, as previously mentioned, a wireless transmitter or access point can include a wireless transceiver device for extending cellular phone service into a business or home or vehicle. In this implementation, one or more vehicles can communicate with the wireless transceiver device, for example, via a code division multiple access (“CDMA”) cellular communication protocol.
[0161] The techniques described herein can be used with a satellite positioning system (“SPS”) that includes any one and / or combination of a number of global navigation satellite systems (“GNSS”), such as the Global Positioning System (“GPS”), the Russian GLONASS system, the European Union Galileo system, and the Chinese Beidou and Beidou-2 systems. Additionally, such techniques can be used with a positioning system that utilizes terrestrial transmitters acting as “pseudosatellites” or a combination of SVs with such terrestrial transmitters. The terrestrial transmitter can include, for example, a terrestrial-based transmitter that broadcasts a PN code or other ranging code (e.g., similar to a GPS or CDMA cellular signal). This transmitter can be assigned a unique PN code to allow identification by a remote receiver. The terrestrial transmitter can be used, for example, to augment the SPS in situations where SPS signals from orbiting SVs may not be available, such as in tunnels, mines, buildings, urban canyons, or other enclosed areas. Another implementation of a pseudosatellite is referred to as a radiobeacon. As used herein, the term “SV” is intended to include terrestrial transmitters acting as pseudosatellites, equivalents of pseudosatellites, and possibly others. As used herein, the terms “SPS signal” and / or “SV signal” are intended to include SPS-like signals from terrestrial transmitters, including terrestrial transmitters acting as pseudosatellites or equivalents of pseudosatellites.
[0162] In the foregoing detailed description, numerous specific details have been set forth in order to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods and apparatuses known to those of ordinary skill in the art have not been described in detail so as not to obscure the claimed subject matter.
[0163] As used herein, the terms “and,” “or,” and “and / or” can include various meanings that are also expected to depend at least in part upon the context in which such terms are used. Generally, “or” when used in reference to a list (such as A, B, or C) is intended to mean A, B, and C (used in an inclusive sense herein) as well as A, B, or C (used in an exclusive sense herein). Additionally, as used herein, the term “one or more” can be used to describe any feature, structure, or characteristic in the singular or can be used to describe a plurality of or some other combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example and the claimed subject matter is not limited to this example.
[0164] Although the presently considered exemplary features have been shown and described, those skilled in the art will understand that various other modifications can be made without departing from the claimed subject matter and equivalents can be substituted. Additionally, many modifications can be made to adapt a particular situation to the teachings of the claimed subject matter without departing from the central concept described herein.
[0165] Accordingly, the claimed subject matter is not intended to be limited to the examples disclosed; such claimed subject matter can also include all aspects falling within the scope of the claims and their equivalents.
[0166] For implementations involving firmware and / or software, the methods can be implemented with modules (e.g., programs, functions, etc.) that perform the functions described herein. Any machine-readable medium tangibly embodying the instructions can be used to implement the methods described herein. For example, software code can be stored in a memory and executed by a processor unit. The memory can be implemented within or external to the processor unit. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory and is not limited to any particular type of memory or to a particular number of memories, or to the type of medium on which the memories are stored.
[0167] When implemented in firmware and / or software, the functions can be stored as one or more instructions or code on a computer-readable storage medium. Examples include computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. Computer-readable media include physical computer storage media. The storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, FLASH, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media, semiconductor storage devices, or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer; as used herein, disk and optical disk include compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk, and Blu-ray disk, where disks typically reproduce data magnetically, while optical disks reproduce data optically with lasers. The above combinations should also be included within the scope of computer-readable media.
[0168] In addition to being stored on a computer-readable storage medium, instructions and / or data can also be provided as signals on a transmission medium included in a communication device. For example, a communication device can include a transceiver having signals indicative of the instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims. That is, the communication device includes a transmission medium having signals indicative of information for performing the disclosed functions. At a first time, the transmission medium included in the communication device can include a first portion of the information to perform the disclosed functions, and at a second time, the transmission medium included in the communication device can include a second portion of the information to perform the disclosed functions.
Claims
1. A method for a self-driving vehicle to enter an intersection, comprising: determining a braking distance for the self-driving vehicle based on vehicle external sensor data, vehicle internal sensor data, vehicle capabilities, or external V2X inputs, or a combination thereof, wherein the braking distance for the self-driving vehicle is at least partially based on tire pressure or tire traction data for the self-driving vehicle, or a combination thereof; sending a first message from the self-driving vehicle to a roadside unit RSU, wherein the first message includes an identification data element for the self-driving vehicle and a braking distance data element for the self-driving vehicle; receiving a second message from the RSU at least partially based on the braking distance for the self-driving vehicle, the second message including one or more instructions regarding the self-driving vehicle's entry into the intersection; and controlling the self-driving vehicle's entry into the intersection in response to the one or more instructions received from the RSU.
2. The method for intersection entry according to claim 1, wherein, the braking distance for the self-driving vehicle is at least partially based on weather conditions.
3. The method for intersection entry according to claim 1, wherein, the tire traction data is determined by a traction control sensor.
4. The method for intersection entry according to claim 1, wherein, the tire traction data is at least partially based on road surface conditions.
5. The method for intersection entry according to claim 1, wherein, the tire traction data is at least partially based on camera data.
6. The method for intersection entry according to claim 1, wherein, the tire traction data is at least partially based on tire wear or tire brand capabilities, or a combination thereof.
7. The method for intersection entry according to claim 1, wherein, the braking distance data element is at least partially based on brake pad wear or brake brand and capabilities, or a combination thereof.
8. The method for intersection entry according to claim 1, wherein, the braking distance data element is at least partially based on engine state.
9. A self-driving vehicle, comprising: one or more wireless transceivers; vehicle internal sensors; vehicle external sensors; a memory; and one or more processors communicatively coupled to the one or more wireless transceivers, the vehicle internal sensors, the vehicle external sensors, and the memory, and wherein the one or more processors are configured to: determine a braking distance for the self-driving vehicle based on data from the vehicle external sensors, data from the vehicle internal sensors, vehicle capabilities, or external V2X inputs, or a combination thereof, wherein the braking distance for the self-driving vehicle is at least partially based on tire pressure or tire traction data for the self-driving vehicle, or a combination thereof; send a first message from the self-driving vehicle to a roadside unit RSU, wherein the first message includes an identification data element for the self-driving vehicle and a braking distance data element for the self-driving vehicle; Receive a second message from the RSU at least partially based on the braking distance for the self-driving vehicle, the second message including one or more instructions regarding the intersection entry of the self-driving vehicle; and Control the intersection entry of the self-driving vehicle in response to the one or more instructions received from the RSU.
10. The self-driving vehicle according to claim 9, wherein, The braking distance for the self-driving vehicle is at least partially based on weather conditions.
11. The self-driving vehicle according to claim 9, wherein, The tire traction data is determined by a traction control sensor.
12. The self-driving vehicle according to claim 9, wherein, The tire traction data is at least partially based on road surface conditions.
13. The self-driving vehicle according to claim 9, wherein, The tire traction data is at least partially based on camera data.
14. The self-driving vehicle according to claim 9, wherein, The tire traction data is at least partially based on tire wear or tire brand capabilities or a combination thereof.
15. The self-driving vehicle according to claim 9, wherein, The braking distance data element is at least partially based on brake pad wear or brake brand and capabilities or a combination thereof.
16. The self-driving vehicle according to claim 9, wherein, The braking distance data element is at least partially based on engine state.
17. A self-driving vehicle, comprising: Components for determining the braking distance for the self-driving vehicle based on vehicle external sensor data, vehicle internal sensor data, vehicle capabilities, or external V2X inputs or a combination thereof, wherein the braking distance for the self-driving vehicle is at least partially based on the tire pressure or tire traction data for the self-driving vehicle or a combination thereof; Components for sending a first message from the self-driving vehicle to a roadside unit RSU, wherein the first message includes an identification data element for the self-driving vehicle and a braking distance data element for the self-driving vehicle; Components for receiving a second message from the RSU at least partially based on the braking distance for the self-driving vehicle, the second message including one or more instructions regarding the intersection entry of the self-driving vehicle; and Components for controlling the intersection entry of the self-driving vehicle in response to the one or more instructions received from the RSU.
18. The self-driving vehicle according to claim 17, wherein, The braking distance for the self-driving vehicle is at least partially based on weather conditions.
19. The self-driving vehicle according to claim 17, wherein, The tire traction data is determined by a traction control sensor.
20. The self-driving vehicle according to claim 17, wherein, The tire traction data is at least partially based on road surface conditions.
21. The self-driving vehicle according to claim 17, wherein, The tire traction data is at least partially based on camera data.
22. The self-driving vehicle according to claim 17, wherein, The tire traction data is at least partially based on tire wear or tire brand capabilities or a combination thereof.
23. The self-driving vehicle according to claim 17, wherein, The braking distance data element is at least partially based on brake pad wear or brake brand and capabilities or a combination thereof.
24. The self-driving vehicle according to claim 17, wherein, the braking distance data element is at least partially based on the engine state.
25. A non-transitory computer-readable medium storing computer-readable instructions that cause one or more processors on a self-driving vehicle to perform the following operations: Determine a braking distance for the self-driving vehicle based on vehicle external sensor data, vehicle internal sensor data, vehicle capabilities, or external V2X input or a combination thereof, wherein, the braking distance for the self-driving vehicle is at least partially based on tire pressure or tire traction data for the self-driving vehicle or a combination thereof; Send a first message from the self-driving vehicle to a roadside unit RSU, wherein the first message includes identification data elements for the self-driving vehicle and braking distance data elements for the self-driving vehicle; Receive a second message from the RSU at least partially based on the braking distance for the self-driving vehicle, the second message including one or more instructions regarding intersection entry of the self-driving vehicle; and Control the intersection entry of the self-driving vehicle in response to the one or more instructions received from the RSU.
26. The non-transitory computer-readable medium according to claim 25, wherein, the braking distance for the self-driving vehicle is at least partially based on weather conditions.
27. The non-transitory computer-readable medium according to claim 25, wherein, the tire traction data is determined by a traction control sensor.
28. The non-transitory computer-readable medium according to claim 25, wherein, the tire traction data is at least partially based on road surface conditions.
29. The non-transitory computer-readable medium according to claim 25, wherein, the tire traction data is at least partially based on tire wear or tire brand capabilities or a combination thereof.
30. The non-transitory computer-readable medium according to claim 25, wherein, the braking distance data element is at least partially based on brake pad wear or brake brand and capabilities or a combination thereof.