System and method for assisting in evasive steering

Abstract

The invention relates to a system and method for assisting in evasive steering. The method is implemented by a computer, which, when executed by data processing hardware, causes the data processing hardware to perform operations including determining vehicle attitude data of a host vehicle, maintaining a range buffer using the vehicle attitude data, detecting a steering maneuver of the host vehicle, and transmitting the steering maneuver to the host vehicle. A relative attitude of the host vehicle is determined using a mileage buffer at the start of steering, a mileage path for aligning a heading of the host vehicle with a heading of the relative attitude is formulated, and steering is completed according to the mileage path.

Description

[0001] introduction

[0002] The information provided in this section is for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors is not admitted, either explicitly or implicitly, as prior art against the present disclosure to the extent described in this section and insofar as the described aspects may not otherwise be considered prior art at the time of filing. Technical Field

[0003] The present disclosure relates generally to a system and method for vehicle stabilization, and more particularly, to a system and method for vehicle stabilization after an evasive steering maneuver. Background Art

[0004] Vehicles are often equipped with advanced driver assistance systems (ADAS) that can help drivers maneuver the vehicle. For example, maintaining good lane following during evasive steering maneuvers or recovering from them can be challenging in ADAS-equipped vehicles when lane markings are absent or perception is degraded. The shortcomings of existing systems and methods are addressed through various aspects of the present disclosure. Summary of the Invention

[0005] In one configuration, a computer-implemented method is provided that, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include determining vehicle pose data for a host vehicle, maintaining a odometry buffer using the vehicle pose data, detecting a steering maneuver of the host vehicle, determining a relative pose of the host vehicle using the odometry buffer at the start of the steering maneuver, developing a odometry path for aligning a heading of the host vehicle with a heading of the relative pose, and completing the steering maneuver according to the odometry path.

[0006] The method may include one or more of the following aspects. For example, collecting vehicle posture data may also include a first state, a second state, and a third state of the host vehicle. The first state may be the x-position of the host vehicle, the second state may be the y-position of the host vehicle, and the third state may be the heading of the host vehicle.

[0007] According to another aspect, determining the relative pose may include determining a heading of a starting pose of the host vehicle at a point in time before the steering maneuver begins.

[0008] In at least one example, completing the steering maneuver according to the mileage path can also include aligning a heading of the host vehicle with a heading of the relative attitude.

[0009] According to at least one aspect, maintaining the mileage buffer may further include updating the mileage buffer according to a faulty operating mode caused by a hardware fault, a sensor fault, or a software fault. Updating the mileage buffer according to the faulty operating mode may include updating the mileage buffer using sensor data directly from a sensor system.

[0010] In another configuration, a vehicle management system is provided that includes an advanced driver assistance system including a trajectory control module and a steering control module associated with path planning; data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include determining vehicle pose data for a host vehicle, maintaining a odometry buffer using the vehicle pose data, detecting a steering maneuver of the host vehicle, determining a relative pose of the host vehicle using the odometry buffer at the start of the steering maneuver, developing a odometry path for aligning a heading of the host vehicle with a heading of the relative pose, and completing the steering maneuver according to the odometry path.

[0011] The vehicle management system may include one or more of the following aspects. For example, collecting vehicle posture data may also include a first state, a second state, and a third state of the host vehicle. The first state may be the x-position of the host vehicle, the second state may be the y-position of the host vehicle, and the third state may be the heading of the host vehicle.

[0012] In at least one example, determining the relative pose may include determining a heading of a starting pose of the host vehicle at a point in time before the steering maneuver begins.

[0013] According to at least one aspect, completing the steering maneuver according to the mileage path can further include aligning a heading of the host vehicle with a heading of the relative attitude.

[0014] According to another aspect, maintaining the mileage buffer may further include updating the mileage buffer according to a faulty operating mode due to a hardware fault, a sensor fault, or a software fault. Updating the mileage buffer according to the faulty operating mode may include updating the mileage buffer using sensor data directly from a sensor system.

[0015] In another configuration, a computer-implemented method is provided that, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include receiving sensor data from one or more wheel speed sensors and an inertial measurement unit of a host vehicle, maintaining a starting pose of the vehicle in a range buffer in a range memory, providing the starting pose to one or more modules for path planning of the host vehicle, and formulating a range path for stabilizing the host vehicle, wherein the range path is formulated using a relative pose corresponding to the starting pose.

[0016] The method may include one or more of the following aspects. For example, maintaining the starting posture data may further include a first state, a second state, and a third state of the host vehicle. The first state may be the x-position of the host vehicle, the second state may be the y-position of the host vehicle, and the third state may be the heading of the host vehicle.

[0017] According to at least one aspect, formulating the mileage route further includes locating the breadcrumb route to a coordinate system of the host vehicle.

[0018] According to yet another aspect, the method may further include transferring the breadcrumb trail from the target vehicle to the host vehicle.

[0019] In yet another configuration, a system is provided and includes data processing hardware and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include determining vehicle pose data for a host vehicle, maintaining a odometry buffer using the vehicle pose data, detecting a steering maneuver of the host vehicle, determining a relative pose of the host vehicle using the odometry buffer at the start of the steering maneuver, developing a odometry path for aligning a heading of the host vehicle with a heading of the relative pose, and completing the steering maneuver according to the odometry path. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are for illustrative purposes only of selected configurations and are not intended to limit the scope of the present disclosure.

[0021] Figure 1 is a schematic diagram of a vehicle environment including a vehicle management system according to the principles of the present disclosure;

[0022] Figure 2 is an enlarged schematic diagram illustrating an example of a vehicle management system according to the principles of the present disclosure;

[0023] Figure 3 The steering maneuver around the object is completed according to the principles of the present disclosure Figure 1 Top view of the vehicle;

[0024] Figure 4A is a top view of a conventional vehicle attempting to complete a steering maneuver around an object with no nearby lane markings;

[0025] Figure 4B According to the principles of this disclosure Figure 1 A top view of a vehicle completing a steering maneuver around an object without nearby lane markings;

[0026] Figure 5A is a top view of a conventional vehicle attempting to complete a steering maneuver around an object relative to nearby lane markings;

[0027] Figure 5B According to the principles of this disclosure Figure 1 A top view of a vehicle completing a steering maneuver around an object relative to nearby lane markings;

[0028] Figure 6 is in a first state and a second state according to the principles of the present disclosure Figure 1 Top view of the vehicle;

[0029] Figure 7 is a method of following a breadcrumb path to a target vehicle according to the principles of the present disclosure Figure 1 A top view of the vehicle; and

[0030] Figure 8 It shows Figure 2 A flow chart of the operation of a vehicle management system.

[0031] Corresponding reference characters indicate corresponding parts throughout the several views of the drawings. DETAILED DESCRIPTION

[0032] Example configurations will now be described more fully with reference to the accompanying drawings. The example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configurations of the present disclosure. It will be apparent to those of ordinary skill in the art that specific details need not be employed, that the example configurations may be embodied in many different forms, and that the specific details and example configurations should not be construed as limiting the scope of the present disclosure.

[0033] The terms used herein are only used to describe the purpose of specific exemplary configurations and are not intended to be limiting. As used herein, the singular articles "a", "an" and "the" may also be intended to include plural forms, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "including" and "having" are inclusive and therefore specify the presence of features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts and / or groups thereof. The method steps, processes and operations described herein should not be interpreted as necessarily requiring them to be performed in the specific order discussed or shown, unless specifically identified as an execution order. Additional or alternative steps may be adopted.

[0034] When an element or layer is referred to as being "on," "engaged to," "connected to," "attached to," or "coupled to" another element or layer, it may be directly on, directly engaged, connected, attached to, or coupled to the other element or layer, or there may be intervening elements or layers. Conversely, when an element is referred to as being "directly on," "directly engaged to," "directly connected to," "directly attached to," or "directly coupled to" another element or layer, there may be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.). As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0035] The terms "first", "second", "third" etc. may be used in this article to describe various elements, components, regions, layers and / or parts. These elements, components, regions, layers and / or parts should not be limited by these terms. These terms can only be used to distinguish one element, component, region, layer or part from another region, layer or part. Unless the context clearly indicates, terms such as "first", "second" and other numerical terms do not imply an order or sequence. Therefore, without departing from the teachings of the example configurations, the first element, component, region, layer or part discussed below may be referred to as a second element, component, region, layer or part.

[0036] In this application, including the definitions below, the term "module" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor (shared, dedicated, or grouped) that executes code; a memory (shared, dedicated, or grouped) that stores code executed by the processor; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip.

[0037] The term "code" as used above may include software, firmware and / or microcode, and may refer to programs, routines, functions, classes and / or objects. The term "shared processor" encompasses a single processor that executes some or all code from multiple modules. The term "group processor" encompasses a processor that, in combination with additional processors, executes some or all code from one or more modules. The term "shared memory" encompasses a single memory that stores some or all code from multiple modules. The term "group memory" encompasses memory that, in combination with additional memory, stores some or all code from one or more modules. The term "memory" may be a subset of the term "computer-readable medium". The term "computer-readable medium" does not encompass transient electrical and electromagnetic signals that propagate through the medium, and therefore may be considered to be both tangible and non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic storage, and optical storage.

[0038] The apparatus and methods described herein may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data.

[0039] A software application (i.e., a software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0040] Non-transitory memory can be a physical device used to temporarily or permanently store programs (e.g., sequences of instructions) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0041] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., a disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0042] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuitry, integrated circuits, specially designed ASICs (application-specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs executable and / or interpretable on a programmable system that includes at least one programmable processor, which can be special-purpose or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to send data and instructions to the storage system, at least one input device, and at least one output device.

[0043] The processes and logic flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware), which execute one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logic flows can also be performed by dedicated logic circuits (e.g., FPGAs (field programmable gate arrays) or ASICs (application-specific integrated circuits)). As an example, processors suitable for executing computer programs include both general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more large-capacity storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operably connected to receive data from it or transmit data to it or both. However, a computer does not need to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and storage devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0044] To provide for interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), an LCD (liquid crystal display) monitor, or a touch screen) for displaying information to the user and, optionally, a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. Additionally, a computer may interact with a user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0045] refer to Figure 1An exemplary vehicle operating environment 10 is provided to illustrate the principles of the present disclosure. The vehicle operating environment 10 includes a vehicle 100 and a vehicle service center 20. For illustration purposes, the vehicle operating environment 10 is shown as including a single vehicle service center 20. However, in other examples, the vehicle operating environment 10 may include multiple vehicle service centers 20 communicating via a network 40 (e.g., the Internet, a cellular network).

[0046] Vehicle 100 includes a vehicle management system 110, which includes a sensor system 120, a computing system 130, a steering system 140, a vehicle dynamics system 150, and an advanced driver assistance system (ADAS) 160. As vehicle 100 maneuvers around environment 10, sensor system 120 includes various sensor subsystems 122, 122a-122c configured to collect sensor data 123, 123a-123c related to characteristics of environment 10 and / or the state of vehicle 100. For example, sensor subsystem 122 includes a vehicle exterior sensor subsystem 122a configured to measure or obtain external environmental data 123a (e.g., weather or surrounding objects (e.g., vehicles, pedestrians, etc.)), an interior sensor subsystem 122b configured to measure interior environmental data 123b (e.g., vehicle occupancy), and / or an ADAS sensor subsystem 122c configured to measure or obtain vehicle operating data 123c (e.g., operating parameters). The ADAS sensor subsystem 122c may include an inertial measurement unit (IMU) 124, one or more wheel speed sensors 125, and other sensors for obtaining vehicle operating data 123c. When the sensor system 120 collects sensor data 123, the computing system 130 is configured to store, process, and / or transmit the sensor data 123 within the vehicle operating environment 10. In order to perform computing tasks related to the sensor data 123, the computing system 130 of the vehicle 100 includes data processing hardware 132 and memory hardware 134. The data processing hardware 132 is configured to execute instructions stored in the memory hardware 134 to perform computing tasks related to the operation and management of the vehicle 100. Generally speaking, the computing system 130 refers to one or more locations of the data processing hardware 132 and / or the memory hardware 134.

[0047] In some examples, computing system 130 is a local system located on vehicle 100 (e.g., a vehicle control unit). When located on vehicle 100, computing system 130 can be centralized (i.e., in a single location / area on vehicle 100, such as a vehicle control unit), decentralized (i.e., located at various locations around vehicle 100), or a hybrid combination of the two (e.g., having mostly centralized hardware and a small amount of decentralized hardware). To illustrate some of the differences, a decentralized computing system 130 can allow processing to occur at an active location, while a centralized computing system 130 can allow a central processing hub to communicate with systems located at various locations on vehicle 100.

[0048] Additionally or alternatively, computing system 130 includes computing resources located remotely from vehicle 100. For example, computing system 130 can communicate with remote vehicle computing system 30 (e.g., a remote computer / server or a cloud-based environment) via network 40. Much like computing system 130, remote vehicle computing system 30 includes remote computing resources, such as remote data processing hardware 32 and remote memory hardware 34. Here, sensor data 123 or other processed data (e.g., data processed locally by computing system 130) can be stored in remote vehicle computing system 130 and can be accessed by computing system 130. In some examples, computing system 130 is configured to utilize remote resources 32, 34 as extensions of computing resources 132, 134, such that resources of computing system 130 can reside on resources of remote vehicle computing system 30.

[0049] refer to Figure 1 , one or more wheels 102 (i.e., front wheels 102a and rear wheels 102b) are coupled to a suspension 104 of the vehicle 100. A steering system 140 is capable of monitoring and controlling the position and / or direction of the wheels 102. For example, the steering system 140 may include a steering column 142 coupled to the suspension 104 and a steering wheel 144 coupled to the steering column 142. The steering system 140 may include one or more additional components, such as a steering box 146 and a steering gear 148, so that torque can be applied to the steering column 142, whether by a motor coupled to the steering column 142 or by the driver applying torque to the steering column 142 through the steering wheel 144, to maintain control and position of the front wheels 102a.

[0050] The vehicle dynamics control system 150 is capable of monitoring and controlling one or more electronic aspects of the vehicle 100, such as continuously monitoring and / or controlling the position or attitude 152 of the vehicle 100, e.g. Figure 2The steering system 140 can provide actual wheel angles 149 as input to a vehicle dynamics control system 150, which can change a posture 152 of the vehicle 100. The posture 152 can include, for example, a first state (e.g., x-position) 152a, a second state (e.g., y-position) 152b, and a third state (e.g., heading) 152c.

[0051] ADAS160 is capable of monitoring and controlling one or more electronic aspects of the vehicle 100. For example, ADAS160 can monitor and control one or more subsystems of the vehicle 100, such as the steering system 130. In other words, for example, ADAS160 can communicate with the steering system 130 to maintain a good trajectory for the vehicle 100 or to restore the trajectory after an evasive steering maneuver. When the construction and knowledge (i.e., perception) of the environment deteriorate, stabilizing the vehicle 100 after an evasive maneuver can be challenging, but it is desirable to avoid additional hazards as the vehicle 100 continues on its path. ADAS160 may include one or more modules for evaluating and / or storing sensor data 123 of the sensor system 120 and providing instructions to one or more systems of the vehicle 100 (e.g., the steering system 140) to maintain a good trajectory after an evasive maneuver. For example, ADAS160 may include a trajectory control module 170 and a steering control module 180.

[0052] Trajectory control module 170 can receive postures 152, 152a-152c from vehicle dynamics control system 150 and calculate a commanded steering angle 172. Commanded steering angle 172 can be provided to steering control module 180 for calculating torque 182 for vehicle steering system 140. Vehicle steering system 140 can receive and apply calculated torque 182 to modify wheel angle 149 accordingly. Trajectory control module 170 can include range memory 200, which can store (i.e., save, record, etc.), for example, the postures 152 of vehicle 100 while driving. Range memory 200 can be desirable to stabilize vehicle 100 when environmental perception is degraded (e.g., lane markings are not perceived). Range memory 200 can also be desirable to enhance robustness of environmental perception when perception is generally unaffected (e.g., lane markings are perceived). For example, the range buffer 200 may use sensor data 123 (such as data 123 c from the ADAS sensor subsystem 122 c) and / or the pose 152 from the vehicle dynamics control system 150 to estimate changes in position over time and formulate a path for stabilizing the vehicle 100. In other words, the range buffer 200 may update or continuously maintain the range buffer 202 with the pose 152 of the vehicle 100 as the vehicle 100 travels, so that trajectory details can be recalled during evasive and / or dynamic steering maneuvers and robust collision avoidance can be improved.

[0053] The trajectory control module 170 may also include a planning module 204 for determining a path for the vehicle 100. The planning module 204 may be configured to receive a starting posture 206 from the mileage storage 200, and more specifically, from the mileage buffer 202. The starting posture 206 may be referred to as the time at which the vehicle 100 is on the first path 208 ( Figure 3 ) on the pose 152. The planning module 204 can determine a final or relative pose 210 relative to the starting pose 206. In other words, the planning module 204 can be configured to determine the final or relative pose 210 at time t if the vehicle 100 does not initiate the evasive steering maneuver. n The final pose 212 can be used to refer to the pose 152 of the vehicle 100 when the vehicle's heading 152c is aligned with the heading 210c of the relative pose 210.

[0054] As will be discussed in the examples below, the range memory 200 and / or range buffer 200 can be maintained with the pose 152 and accessed by the planning module 204 so that a second or range path 214 can be formulated to stabilize the vehicle after the initiation of the evasive steering maneuver. In practice, the range path 214 may be desired so that the heading 212c of the vehicle 100 can match the heading 210c relative to the pose 210. More specifically, the commanded steering angle 172 can be determined based on the range path 214 so that the heading 212c of the vehicle 100 can match the heading 210c relative to the pose 210. Typically, without the range memory 200, the vehicle 100 would otherwise follow the evasive path 216, which could result in, for example, an uncontrolled lane departure.

[0055] In the event that sensor data is uncertain (e.g., due to a sensor malfunction, hardware failure, and / or software failure), the mileage buffer 202 may operate in a faulty operating mode. For example, if the mileage filter of the ADAS 160 that collects and filters sensor data from the sensor system 120 has not converged and / or detects anomalies in the data, the mileage buffer 202 may operate in a faulty operating mode. During the faulty operating mode, for example, the mileage buffer 202 may be updated based on sensor data received at the ADAS sensor system (i.e., directly from the sensors) rather than deriving data from the mileage filter. Once the vehicle 100 recovers from the faulty operating mode (i.e., the sensor data is no longer uncertain), the mileage buffer 202 resumes consuming data from the mileage filter.

[0056] refer to Figure 3, vehicle 100 is shown completing an evasive maneuver around object 106 (e.g., a vehicle, pedestrian, etc.). As described above, vehicle 100 would typically follow avoidance path 216 to avoid object 106. However, here, vehicle 100 may follow odometry path 214 so that vehicle's heading 212c is aligned with heading 210c of relative pose 210. In other words, vehicle 100 may follow odometry path 214 so that heading 212c of final pose 212 is commensurate with heading 210c of relative pose 210. Between starting pose 206 and final pose 212, the vehicle may have one or more additional poses 207, 209, which may be stored (i.e., recorded, saved, etc.) in odometry memory 200, and more specifically, in odometry buffer 202. For example, it may be desirable to continuously maintain the mileage buffer 202 with the pose 152 of the vehicle 100 so that the planning module 204 can access trajectory details regarding the location of the vehicle 100 and modify the mileage path 214 accordingly.

[0057] refer to Figure 4A , the existing vehicle 101 often becomes unstable during an evasive steering maneuver around the object 106, and this is especially true when the existing vehicle 101 attempts an evasive steering maneuver without lane lines. Figure 4B , when the vehicle 100 relies on the mileage memory 200 ( Figure 2 and 3 ) to formulate the mileage path 214, the stability of the vehicle 100 can be maintained while completing the evasive steering maneuver. Figure 5A , during an evasive steering maneuver, a degradation of perception (i.e., loss of lane markings 103) is possible, and conventional vehicles 101 typically become unstable during such maneuvers. Figure 5B , when the vehicle 100 relies on the mileage memory 200 ( Figure 2 and 3 ) to formulate the mileage path 214 and the nearby lane markings 103 may be used to position the vehicle 100, the stability of the vehicle 100 may be maintained such that the final heading 212c is aligned with the relative heading 210c based on the starting heading 204c.

[0058] According to another aspect of the present invention, the mileage memory 200 can be implemented with a model predictive controller (MPC). In other words, the mileage memory 200 can be configured to provide the MPC with the attitude of the vehicle 100 so that, for example, the commanded steering angle can be calculated and controlled based on the mileage path and the reference path.

[0059] refer to Figure 6, vehicle 100 is shown relative to first lane marker 304 at first sampling time 302 and relative to second lane marker 308 at second sampling time 306. For example, it may be desirable to fuse first lane marker 304 and second lane marker 308 so that first lane marker 304 and second lane marker 308 can be filtered. To this end, first lane marker 304 and second lane marker 308 may be transformed so that they are in the same coordinate system. In this example, odometer memory 200 may provide a diameter pose 310 of vehicle 100, so that first lane marker 304 and second lane marker 310 may be transformed to the same coordinate system.

[0060] refer to Figure 7 , vehicle 100 is shown traveling through intersection 400 along breadcrumb path 402. Odometer memory 200 may be accessed so that trajectory control module 170, and more specifically planning module 204, may form breadcrumb path 402 from target vehicle 100′ to vehicle 100 on road 404. For example, it may be desirable to reference starting pose 206 of vehicle 100 to establish odometer path 214 and locate breadcrumb path 402 to coordinate system 406 of vehicle 100. Breadcrumb path 402 may then be translated from target vehicle 100′ back to vehicle 100.

[0061] refer to Figure 8 , a method 500 for stabilizing the vehicle 100 when initiating an evasive steering maneuver using the range memory 200 is provided.

[0062] At 502 , the method 500 is initiated. In practice, the method 500 is initiated when the operator starts the ignition of the vehicle 100 .

[0063] At 504, sensor data 123 may be collected by the sensor system 120. For example, the ADAS sensor module 122c may continuously provide the vehicle pose 152 while the vehicle 100 is traveling or stationary.

[0064] At 506 , the range memory 200 , and more specifically, the range buffer 202 , may be maintained with the vehicle pose 152 so that it may be referenced by the computing system 130 if an evasive steering maneuver is detected.

[0065] At 508 , if an evasive steering maneuver is initiated, whether by the driver or automated by the vehicle 100 , the method 500 will proceed to 510 . The vehicle 100 will continue to collect data at 504 and maintain the range buffer at 306 until an evasive steering maneuver is detected.

[0066] At 510 , the mileage path 214 may be formulated using the relative pose 210 of the vehicle 100 such that the final heading 212 c is aligned with the relative heading 206 c relative to the starting heading 204 c .

[0067] At 512 , the vehicle 100 maintains stability and completes the evasive steering maneuver according to the mileage path 214 .

[0068] At 514 , method 500 ends.

[0069] Many embodiments have been described. However, it will be appreciated that various modifications can be made without departing from the spirit and scope of the present disclosure. Therefore, other embodiments are within the scope of this application.

[0070] The foregoing description is provided for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but are interchangeable where applicable and can be used in a selected configuration, even if not specifically shown or described. They may also vary in many ways. Such variations should not be considered as departing from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A computer-implemented method that, when executed by data processing hardware, causes the data processing hardware to perform operations comprising: determining vehicle posture data of the host vehicle; Maintaining a range buffer using vehicle attitude data; detecting steering maneuvers of the host vehicle; Using odometry buffers to determine the relative attitude of the host vehicle when initiating a steering maneuver; formulating a mileage path for aligning a heading of the host vehicle with a heading of the relative attitude; and The steering maneuver is performed according to the mileage path. 2 . The method of claim 1 , wherein collecting vehicle posture data further comprises a first state, a second state, and a third state of the host vehicle. 3 . The method of claim 2 , wherein the first state is the x-position of the host vehicle, the second state is the y-position of the host vehicle, and the third state is the heading of the host vehicle. The method of claim 1 , wherein determining the relative attitude comprises determining a heading of a starting attitude of the host vehicle at a point in time prior to initiating the steering maneuver. The method of claim 4 , wherein a starting posture of the host vehicle is used to complete the steering maneuver.

6. The method of claim 1 , wherein completing the steering maneuver according to the mileage path further comprises aligning a heading of the host vehicle with a heading of the relative attitude. 7 . The method of claim 1 , wherein maintaining the mileage buffer further comprises updating the mileage buffer according to a faulty operating mode due to a hardware failure, a sensor failure, or a software failure. 8 . The method of claim 7 , wherein updating the mileage buffer according to the faulty operating mode comprises updating the mileage buffer using sensor data directly from a sensor system. 9 . The method of claim 1 , wherein the mileage buffer is continuously maintained with the attitude of the vehicle during travel of the vehicle. 10 . The method of claim 9 , wherein the vehicle's attitude can be continuously retrieved from the odometry buffer during an evasive steering maneuver.

Images