Vehicle control method and device, electronic equipment and autonomous vehicle

Abstract

The present disclosure provides a vehicle control method, relates to the technical field of automatic driving, and particularly relates to the technical field of intelligent traffic. A specific implementation scheme is as follows: in the process of vehicle operation, a vehicle control command generated by a controller of the vehicle and a vehicle planning path are acquired; in response to detecting controller failure, a safety level is determined according to an operating parameter of the vehicle; and the vehicle is controlled to stop according to a safety strategy of a corresponding level according to the safety level, wherein the safety strategy comprises a slow braking strategy based on the vehicle control command, a slow braking strategy based on the vehicle planning path, and a sudden braking strategy based on wheel orientation. The present disclosure also provides a vehicle control device, an electronic device, a storage medium and an automatic driving vehicle.

Description

Technical Field

[0001] This disclosure relates to the field of autonomous driving technology, and more particularly to the field of intelligent transportation technology. More specifically, this disclosure provides a vehicle control method, apparatus, electronic device, storage medium, and autonomous vehicle. Background Technology

[0002] A malfunction in an autonomous vehicle can lead to unexpected problems such as loss of control of the autonomous driving system, posing safety risks and causing personal injury and property damage. Therefore, knowing how to control a vehicle when it malfunctions is crucial. Summary of the Invention

[0003] This disclosure provides a vehicle control method, apparatus, device, storage medium, and autonomous vehicle.

[0004] According to a first aspect, a vehicle control method is provided, the method comprising: during vehicle operation, acquiring vehicle control commands and a planned vehicle path generated by the vehicle's controller; in response to detecting a controller failure, determining a safety level based on the vehicle's operating parameters; and selecting a corresponding safety strategy to control the vehicle to stop according to the safety level, wherein the safety strategy includes a easing braking strategy based on the vehicle control commands, a easing braking strategy based on the planned vehicle path, and an emergency braking strategy based on wheel orientation.

[0005] According to a second aspect, a vehicle control device is provided, comprising: an acquisition module for acquiring vehicle control commands and a planned vehicle path generated by a vehicle controller during vehicle operation; a first determination module for determining a safety level based on vehicle operating parameters in response to detecting a controller failure; and a control module for selecting a corresponding safety strategy to control the vehicle to stop based on the safety level, wherein the safety strategy includes a easing braking strategy based on vehicle control commands, a easing braking strategy based on the planned vehicle path, and an emergency braking strategy based on wheel orientation.

[0006] According to a third aspect, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method provided according to the present disclosure.

[0007] According to a fourth aspect, a non-transitory computer-readable storage medium is provided storing computer instructions for causing a computer to perform the methods provided in this disclosure.

[0008] According to a fifth aspect, a computer program product is provided, comprising a computer program stored on at least one of a readable storage medium and an electronic device, wherein the computer program, when executed by a processor, implements the method provided in this disclosure.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0011] Figure 1 This is a connection diagram of the autonomous driving domain controller and the chassis controller according to an embodiment of the present disclosure;

[0012] Figure 2 This is a flowchart of a vehicle control method according to an embodiment of the present disclosure;

[0013] Figure 3 This is a schematic diagram of the software architecture of a security system running on a microcontroller unit (MCU) according to an embodiment of the present disclosure.

[0014] Figure 4 This is a block diagram of a vehicle control device according to an embodiment of the present disclosure;

[0015] Figure 5 This is a block diagram of an electronic device for a vehicle control method according to an embodiment of the present disclosure. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0018] In the technical solution disclosed herein, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0019] The autonomous driving domain controller is responsible for functions such as multi-sensor data fusion, localization, path planning, and decision control in autonomous vehicles. It primarily comprises two computing units: a System-on-a-Chip (SOC) and a Microcontroller Unit (MCU). An SOC typically integrates multiple processing units, including a CPU, GPU, and NPU, supporting high-performance computing, graphics computing, AI computing, audio processing, and more, possessing powerful computing capabilities. An MCU, also known as a microcontroller, in the field of autonomous vehicles integrates input and output devices within a single chip for better control. SOCs generally run Linux-like systems, often time-sharing operating systems. MCUs run real-time operating systems, with lower computing power than SOCs, but offering higher stability and security.

[0020] Autonomous driving domain controllers are typically connected directly to the chassis controller of autonomous vehicles to control the vehicles.

[0021] Figure 1 This is a connection diagram of the autonomous driving domain controller and the chassis controller according to an embodiment of the present disclosure.

[0022] like Figure 1 As shown, the autonomous driving domain controller 110 includes a system-on-a-chip (SoC) and a microcontroller unit (MCU). The autonomous driving domain controller 110 is directly connected to the chassis controller 120. The SoC and MCU communicate via Ethernet, and the MCU communicates with the chassis controller 120 via a CAN bus.

[0023] The CAN bus communication method has strict limitations on the message transmission cycle, while the SOC occasionally experiences process lag, system failures, and other issues. These problems can lead to unexpected problems such as loss of control in the autonomous driving system, causing safety risks and resulting in personal injury and property damage. The MCU is equipped with a safety system to recall these autonomous driving system problems and, when necessary, take over vehicle control in place of the SOC, ensuring the reliability of the safe takeover.

[0024] In one example, both the System-on-a-Chip (SOC) and the Microcontroller Unit (MCU) can be redundantly backed up. For instance, the SOC might include a primary SOC and a redundant SOC, and the MCU might include a primary MCU and a redundant MCU. Since the safety of the other SOC cannot be guaranteed if one SOC fails, both the primary and redundant MCUs can initiate takeover of the vehicle if at least one of the primary or redundant SOCs fails. This ensures that if one of the primary or redundant MCUs fails, the other MCU can successfully take over.

[0025] Figure 2 This is a flowchart of a vehicle control method according to an embodiment of the present disclosure.

[0026] The execution entity in this embodiment can be a microcontroller unit (MCU), such as at least one of a main MCU and a redundant MCU.

[0027] like Figure 2 As shown, the vehicle control method 200 includes operations S210 to S230.

[0028] During operation of S210, the vehicle control commands and vehicle planning paths generated by the vehicle controller are acquired during vehicle operation.

[0029] For example, a vehicle's controller can refer to a system-on-a-chip (SOC). During vehicle operation, the SOC can generate vehicle control commands and vehicle path planning based on vehicle driving environment data collected by multiple sensors.

[0030] Vehicle control commands include, for example, lateral control commands for controlling vehicle steering and longitudinal control commands for controlling vehicle acceleration, deceleration, and braking. Vehicle path planning refers to the predicted trajectory for the vehicle.

[0031] The microcontroller unit (MCU) receives vehicle control commands and vehicle planning paths generated by the system-on-a-chip (SOC) in real time and sends them to the chassis controller to control the vehicle to drive based on the vehicle control commands and vehicle planning paths.

[0032] In operation S220, in response to the detection of a controller failure, a safety level is determined based on the vehicle's operating parameters.

[0033] For example, during vehicle operation, the microcontroller unit (MCU) monitors the status data of the system-on-a-chip (SOC) in real time to determine whether the SOC is operating normally.

[0034] The status data of a system-on-a-chip (SoC) includes, for example, heartbeat data, communication data, and service data. If at least one of the heartbeat data, communication data, and service data is abnormal, it can be determined that the SoC has failed.

[0035] In the event of a system-on-a-chip (SoC) failure, the microcontroller unit (MCU) needs to take over vehicle control in place of the SoC.

[0036] In one example, if at least one of the main SOC and the redundant SOC fails, both the main MCU and the redundant MCU can perform operations S210 to S230 of this embodiment to take over the vehicle.

[0037] The microcontroller unit (MCU) can determine the safety level based on the current vehicle operating parameters. Depending on the safety level, a corresponding safety takeover strategy (hereinafter referred to as the safety strategy) is adopted to control the vehicle and bring it to a stop, thereby preventing accidents.

[0038] The current operating parameters of a vehicle can include braking parameters, IMU parameters, MCU parameters, and planned path parameters. The more parameters that are in a normal state, the higher the vehicle's controllability and safety, and therefore the higher the safety level. Conversely, the more parameters that are in an abnormal state, the lower the vehicle's controllability and safety, and therefore the lower the safety level.

[0039] When operating S230, select the corresponding safety policy based on the safety level to control the vehicle to stop.

[0040] For example, based on the above safety operation parameters, three safety levels can be determined, namely Level 1, Level 2, and Level 3, with the safety levels of Level 1, Level 2, and Level 3 decreasing sequentially.

[0041] Each safety level can correspond to a safety strategy. Safety strategies can include a braking mitigation strategy based on vehicle control commands, a braking mitigation strategy based on vehicle planned paths, and an emergency braking strategy based on wheel orientation. Specifically, a braking mitigation strategy based on vehicle control commands can perform braking mitigation according to control commands sent before SOC failure, while a braking mitigation strategy based on vehicle planned paths can perform braking mitigation according to the planned path sent before SOC failure.

[0042] The first level can correspond to a slow braking strategy based on the vehicle's planned path, the second level can correspond to a slow braking strategy based on vehicle control commands, and the third level can correspond to an emergency braking strategy based on wheel orientation.

[0043] Therefore, when the safety level is Level 1, a gentle braking strategy based on the vehicle's planned path is selected to control the vehicle to stop; when the safety level is Level 2, a gentle braking strategy based on vehicle control commands is selected to control the vehicle to stop; and when the safety level is Level 3, an emergency braking strategy based on wheel orientation is selected to control the vehicle to stop.

[0044] In this embodiment, when a controller failure is detected, a corresponding safety strategy is adopted to stop the vehicle based on the current vehicle safety level. This enables precise control of autonomous vehicles in fault conditions and improves vehicle safety.

[0045] Figure 2 The execution entity in the illustrated embodiment can be a microcontroller unit (MCU), specifically a security system set in the MCU.

[0046] The following is combined with Figure 3 The security system provided in this embodiment will be described.

[0047] Figure 3 This is a schematic diagram of the software architecture of a security system running on a microcontroller unit (MCU) according to an embodiment of the present disclosure.

[0048] like Figure 3 As shown, the software architecture of the security system includes bottom-layer software 310 and application-layer software 320. Bottom-layer software 310 includes a Diagnostic Event Manager (DEM) module 311 and a communication module 312. Application-layer software 320 includes a detection module 321, a decision-making module 322, and a control module 323.

[0049] The diagnostic event management module 311 is used to process and store fault data, such as signal loss detection and fault debouncing. The communication module 312 is used to provide basic software communication capabilities, such as signal transmission and reception.

[0050] The detection module 321 is used to detect its own status data and the status data of peripheral devices such as the SOC. The status data includes fault-related data. The detection module 321 can also feed back the detected SOC fault-related data to the SOC and transmit fault-related data to the decision module 322.

[0051] The decision module 322 is used to determine the vehicle's executor and degradation strategy based on the fault data provided by the detection module 321. For example, it determines the vehicle's safety level, whether to take over the vehicle, and what safety strategy to use for takeover.

[0052] The control module 323 is used to execute the security policy after receiving the decision instruction from the decision module 322.

[0053] The detection module 321 will be described in detail below.

[0054] The detection module 321 can perform heartbeat detection, communication data detection, and service data detection on external modules to determine status data such as heartbeat status, communication status, and service status. External modules may include a System-on-Chief Control (SOC), an Inertial Measurement Unit (IMU), and a chassis controller.

[0055] Table 1 shows the detection content of the detection module 321 for each external module.

[0056] Table 1

[0057]

[0058] For each external module, the detection module 321 can perform the detection of the contents shown in Table 1.

[0059] The detection content shown in Table 1 includes detection type, detection method and abnormal judgment criteria.

[0060] The detection types include heartbeat detection, communication detection, abnormal status detection of business data, and abnormal value detection of business data.

[0061] The heartbeat detection methods include detecting whether the detection frequency is abnormal, whether the heartbeat packet times out, and whether the timestamp order is correct. The criterion for determining an abnormal frequency is whether the detected frequency is less than a certain percentage of the design frequency. For example, if the design frequency is 20Hz, and the detected frequency is less than 10Hz or 8Hz, a heartbeat abnormality can be determined. The criterion for determining a heartbeat packet timeout is whether a heartbeat packet has not been received for a certain period beyond the design cycle. For example, if the design cycle is 50ms, and a heartbeat packet has not been received for more than 7 to 8 cycles, a heartbeat packet timeout can be determined. The criterion for determining an abnormal timestamp order is whether the timestamp of the current frame is less than the timestamp of the previous frame; if so, a timestamp abnormality can be determined.

[0062] Communication detection primarily targets the detection of control commands. Detection methods include checking whether the control command signal has timed out. The criterion is whether a control command has not been received for a certain period beyond the design cycle. For example, if the design cycle is 10ms, and no control command has been received for more than 5 to 10 cycles, the control command signal can be considered to have timed out.

[0063] Business data anomaly detection primarily targets the status values ​​of business data. Detection methods include checking whether the status value is abnormal. The judgment criteria are based on the business design values. For example, a speed signal includes a speed value and a reliability status value. If the reliability status values ​​of multiple consecutive (e.g., 5) speed signals all indicate that the speed value is unreliable, then the status value can be determined to be abnormal.

[0064] Business data anomaly detection primarily targets the signal values ​​of business data. Detection methods include checking whether the signal value is abnormal, with the judgment criteria based on the business design values. For example, a speed value higher than 200 km / h can be considered an anomaly.

[0065] The detection module 321 can also detect the MCU's own status. For example, it can obtain voltage and current values ​​through the underlying interface during the task cycle. For example, the MCU may run with multiple cores (e.g., 6 cores), and the operating status of each core can be detected. For example, it can also detect whether the application layer is running normally, whether the underlying software communication layer is running normally, and whether the driver layer is normal.

[0066] Detecting whether the application layer is functioning correctly includes checking whether the decision module 322 and the control module 323 are functioning correctly. Detecting whether the underlying software communication layer is functioning correctly includes checking whether the diagnostic event management module 311 is functioning correctly. Detecting whether the driver layer is functioning correctly includes checking whether the CAN bus and Ethernet are functioning correctly.

[0067] The detection module 321 organizes the detected abnormal data (fault data) and its own status data and sends them to the decision module 322.

[0068] The decision module 322 will be described in detail below.

[0069] The decision module 322 determines whether the MCU should take over the vehicle based on the fault data sent by the detection module 321.

[0070] The conditions under which the MCU takes over the vehicle include SOC failure; that is, the MCU will take over the vehicle if the SOC fails. For example, if any of the judgment criteria in Table 1 above detects an anomaly, it can be determined that the SOC has failed.

[0071] It should be noted that once the MCU has taken over control of the vehicle, even if the SOC recovers from its fault and returns to normal, to ensure vehicle safety, the MCU should continue the entire takeover process, and the SOC should not continue to control the vehicle. Furthermore, if a safety driver is present in the vehicle, manual takeover is permitted. If the driver manually exits the autonomous driving mode, the MCU will no longer take over.

[0072] When the SOC is running normally, it will continuously output control commands and planned routes to the MCU for a period of time (e.g., ten seconds). Therefore, if the SOC fails, the MCU will receive the control commands and planned routes sent before the SOC failed, which can be used as the SOC's last words.

[0073] After determining that the State of the Occupant (SOC) has failed, the current vehicle's safety level can be determined based on its operating parameters, so as to determine which safety strategy to use for takeover.

[0074] According to embodiments of this disclosure, the operating parameters include: braking parameters, inertial measurement unit (IMU) parameters, and vehicle planning path parameters; determining the safety level based on the vehicle's operating parameters includes: determining the safety level as a first level in response to the operating parameters meeting a first condition, wherein the first condition is that the braking parameters, IMU parameters, and vehicle planning path parameters are all in a normal state; determining the safety level as a second level in response to the operating parameters meeting a second condition, wherein the second condition is that the braking parameters and vehicle planning path parameters are both in a normal state; and determining the safety level as a third level in response to the operating parameters meeting a third condition, wherein the third condition is any condition other than the first and second conditions.

[0075] It should be noted that the operating parameters also include the MCU's own parameters. When the MCU's own parameters are normal, the MCU can take over the vehicle. Therefore, the first, second, and third conditions mentioned above all include the MCU's own parameters being in a normal state.

[0076] Table 2 shows the conditions that each security level (or security policy) must meet.

[0077] Table 2

[0078]

[0079] As shown in Table 2, if the current vehicle meets the first condition, the safety level is determined to be Level 1, and the safety strategy is a gradual braking strategy based on the vehicle's planned path. If the current vehicle meets the second condition, the safety level is determined to be Level 2, and the safety strategy is a gradual braking strategy based on vehicle control commands. If the current vehicle meets the third condition, the safety level is determined to be Level 3, and the safety strategy is an emergency braking strategy based on wheel orientation.

[0080] Compared to the first condition, the second condition allows for IMU (Inertial Measurement Unit) malfunctions. Under the first condition, vehicle controllability is higher. The vehicle-planned path-based braking strategy corresponding to the first condition relies on the IMU to control the vehicle while braking along the planned path; therefore, this strategy is the most aggressive. The vehicle-control command-based braking strategy only needs to periodically send control commands to the chassis controller and does not participate in vehicle control, thus it is relatively conservative. The wheel-orientation-based emergency braking strategy is the most conservative direct braking method.

[0081] According to embodiments of this disclosure, the vehicle control method further includes, in response to a change in the vehicle's operating parameters, determining a safety level downgrade based on conditions met by the changed operating parameters. In response to the safety level downgrade, a safety strategy downgrade is determined.

[0082] In response to changes in vehicle operating parameters, the safety level is downgraded based on the conditions met by the changed operating parameters, including: in response to a change in the condition met by the vehicle operating parameters from a first condition to a second condition, the safety level is downgraded from level one to level two; in response to a change in the condition met by the vehicle operating parameters from a first condition to a third condition, the safety level is downgraded from level one to level three; in response to a change in the condition met by the vehicle operating parameters from a second condition to a third condition, the safety level is downgraded from level two to level three.

[0083] In response to a downgrade in safety level, the determination of a downgraded safety strategy includes: in response to a downgrade in safety level from Level 1 to Level 2, downgrading the braking strategy based on vehicle path planning to a braking strategy based on vehicle control commands; in response to a downgrade in safety level from Level 1 to Level 3, downgrading the braking strategy based on vehicle path planning to an emergency braking strategy based on wheel orientation; and in response to a downgrade in safety level from Level 2 to Level 3, downgrading the braking strategy based on vehicle control commands to an emergency braking strategy based on wheel orientation.

[0084] For example, if a vehicle's operating conditions change, the conditions under which its operating parameters meet change, the safety level changes, and the safety strategy will also change accordingly. In other words, the safety strategy can be interrupted; for instance, if the safety level is downgraded, the safety strategy can be downgraded to a more conservative approach.

[0085] Security levels can be downgraded to a more conservative strategy, but should not be upgraded to a more aggressive one. For example, if a security level is upgraded to enable fault recovery, the current security policy should be maintained, and the upgrade should not be implemented.

[0086] After the MCU controls the vehicle to stop, i.e. after the safety policy is completed, it can continue to detect faults. Once everything returns to normal, it can wait for manual confirmation to resume autonomous driving.

[0087] The control module 323 will be described in detail below.

[0088] The control module 323 is used to perform corresponding operations on the decision commands sent by the decision module 322 to complete the safe execution of the vehicle degradation strategy. The decision commands sent by the decision module 322 include the safety policy determined by the decision module 322.

[0089] The execution of the safety policy may include modifying the data transmitted on the CAN bus through the data transceiver interface provided by the underlying software. For example, in response to the safety policy received from the decision module 322, the control commands transmitted from the SOC may be modified according to the policy, such as changing the acceleration command to a deceleration command, thereby achieving the purpose of controlling the vehicle.

[0090] The three security strategies are explained below.

[0091] The vehicle path-planned braking strategy primarily controls the vehicle to brake gradually along the planned path generated before SOC failure (i.e., the SOC's last words). The MCU can perform control logic based on the trajectory line, IMU data, and real-time data feedback from the chassis.

[0092] According to embodiments of this disclosure, when the safety level is Level 1, selecting a vehicle-planned path-based easing braking strategy to control the vehicle to stop includes: generating a correction instruction for correcting the planned path based on the actual operating environment of the vehicle; determining a correction path based on the correction instruction; and controlling the vehicle to stop based on the correction path.

[0093] The vehicle path planning-based braking strategy not only controls the vehicle to brake along the planned path but also uses an inertial measurement unit (IMU) for vehicle control. For example, if the actual steering angle of the vehicle's steering wheel is insufficient to achieve the planned path, the IMU can be used to determine the vehicle's current acceleration and angular velocity. Based on these acceleration and angular velocity, control commands can be regenerated. These commands can correct the planned path sent before the State of the Vehicle (SOC) failure, generating a corrected path that allows the vehicle to brake along the corrected path until it comes to a stop.

[0094] The advantages of a vehicle path planning-based braking strategy are low data transmission volume and the ability to self-correct to some extent after a deviation occurs, such as by correcting the trajectory line. This strategy offers high controllability. However, this strategy relies on the IMU (Integrated Measurement Unit) and cannot be used if the IMU fails.

[0095] The vehicle-controlled braking strategy, based on vehicle control commands, involves the SOC planning a series of control commands in real time, known as a control command sequence. This sequence instructs the vehicle to brake gradually until it comes to a stop. The control command sequence may include predicted steering and braking control commands needed to bring the vehicle to a complete stop within a future timeframe (e.g., 10 seconds).

[0096] When the MCU triggers the easing braking strategy based on the vehicle's planned path, it will use the sequence of control commands issued before the SOC failed to control the vehicle to stop. The sequence of control commands includes lateral control commands (such as steering) and longitudinal control commands (such as braking), and the commands in the sequence are executed in order.

[0097] According to embodiments of this disclosure, when the safety level is level two, selecting a vehicle control command-based easing braking strategy to control the vehicle to stop includes: determining a control command at a specified time point from the control command sequence as a starting command based on the time point of controller failure; and executing the vehicle control command-based easing braking strategy starting from the starting command in the control command sequence.

[0098] The initial control command in the control command sequence needs to be adjusted accordingly, taking into account the time of fault detection. For example, the control command after a specified time point is determined from the control command sequence as the initial command, and execution begins from this initial command. This specified time point can be determined based on the time when the MCU detects the abnormal heartbeat of the failed SOC.

[0099] The braking strategy based on vehicle control commands has simple logic; the MCU only needs to issue control commands periodically, without relying on other sensors. However, this strategy transmits a large amount of data, and the braking trajectory is not very controllable.

[0100] Emergency braking strategies based on wheel orientation can involve constant deceleration (e.g., -4 m / s²). 2 Brake suddenly until the vehicle comes to a stop.

[0101] Under any strategy, the hazard lights will turn on while braking. After the chassis reports a vehicle speed of 0 m / s for a period of time, it will request to park and engage the handbrake. Once the chassis has confirmed that the handbrake is engaged, it will exit the automatic driving mode.

[0102] This embodiment provides three safety strategies to take over the vehicle. By selecting the corresponding safety strategy under different safety levels, it is possible to achieve fine control of autonomous vehicles in fault conditions.

[0103] Figure 4 This is a block diagram of a vehicle control device according to an embodiment of the present disclosure.

[0104] like Figure 4As shown, the vehicle control device 400 includes an acquisition module 401, a first determination module 402, and a control module 403.

[0105] The acquisition module 401 is used to acquire vehicle control commands and vehicle planning paths generated by the vehicle controller during vehicle operation.

[0106] The first determining module 402 is used to determine the safety level based on the vehicle's operating parameters in response to the detection of a controller failure.

[0107] The control module 403 is used to select a corresponding safety strategy to control the vehicle to stop according to the safety level. The safety strategies include a slow braking strategy based on vehicle control commands, a slow braking strategy based on the vehicle's planned path, and an emergency braking strategy based on wheel orientation.

[0108] According to embodiments of this disclosure, the security levels include a first level, a second level, and a third level, with the security levels decreasing sequentially from the first level to the third level. The control module 403 includes a first control unit, a second control unit, and a third control unit.

[0109] The first control unit is used to select a slow braking strategy based on the vehicle's planned path to control the vehicle to stop when the safety level is at the first level.

[0110] The second control unit is used to select a gentle braking strategy based on vehicle control commands to control the vehicle to stop when the safety level is level two.

[0111] The third control unit is used to select an emergency braking strategy based on wheel orientation to stop the vehicle when the safety level is level three.

[0112] According to embodiments of this disclosure, the vehicle control device 400 further includes a second determining module and a third determining module.

[0113] The second determining module is used to respond to changes in the vehicle's operating parameters and determine a downgrade of the safety level based on the conditions met by the changed operating parameters.

[0114] The third determination module is used to determine the security policy downgrade in response to a security level downgrade.

[0115] The third determining module includes a first determining unit, a second determining unit, and a third determining unit.

[0116] The first determining unit is used to downgrade the braking strategy based on the vehicle planning path to a braking strategy based on the vehicle control command in response to a downgrade of the safety level from the first level to the second level.

[0117] The second determining unit is used to downgrade the easing braking strategy based on the vehicle planning path to an emergency braking strategy based on wheel orientation in response to a downgrade of the safety level from the first level to the third level.

[0118] The third determining unit is used to downgrade the easing braking strategy based on vehicle control commands to an emergency braking strategy based on wheel orientation in response to a downgrade of the safety level from level two to level three.

[0119] According to embodiments of this disclosure, the operating parameters include braking parameters, inertial measurement unit (IMU) parameters, and vehicle planned path parameters. The first determining module includes a fourth determining unit, a fifth determining unit, and a sixth determining unit.

[0120] The fourth determining unit is used to determine the safety level as the first level in response to the operating parameters meeting the first condition, wherein the first condition is that the braking parameters, the inertial measurement unit (IMU) parameters, and the vehicle planning path parameters are all in a normal state.

[0121] The fifth determining unit is used to determine the safety level as the second level in response to the operating parameters meeting the second condition, wherein the second condition is that both the braking parameters and the vehicle planning path parameters are in a normal state.

[0122] The sixth determining unit is used to determine the safety level as the third level in response to the operating parameters meeting the third condition, wherein the third condition is any condition other than the first and second conditions.

[0123] The second determining module includes a seventh determining unit, an eighth determining unit, and a ninth determining unit.

[0124] The seventh determining unit is used to determine the safety level from the first level to the second level in response to the condition that the vehicle's operating parameters meet being downgraded from the first condition to the second condition.

[0125] The eighth determining unit determines the safety level from the first level to the third level in response to the condition that the vehicle's operating parameters meet being downgraded from the first condition to the third condition.

[0126] The ninth determining unit is used to determine the safety level from the second level to the third level in response to the condition that the vehicle's operating parameters meet being downgraded from the second condition to the third condition.

[0127] The first control unit includes a generation subunit, a correction subunit, and a control subunit.

[0128] The generation subunit is used to generate correction instructions for revising the planned path based on the actual operating environment of the vehicle.

[0129] The correction subunit is used to determine the correction path according to the correction instruction.

[0130] The control subunit is used to control the vehicle to stop according to the corrected path.

[0131] According to embodiments of this disclosure, vehicle control commands include a sequence of control commands. The second control unit includes a determining subunit and an executing subunit.

[0132] The determination subunit is used to determine the control command at a specified time point from the control command sequence as the starting command based on the time point of controller failure.

[0133] The execution subunit is used to execute a braking strategy based on vehicle control commands, starting from the initial command in the control command sequence.

[0134] The vehicle control unit 400 also includes a detection module and a fourth determination module.

[0135] The detection module is used to detect the controller's status data, which includes heartbeat data, communication data, and service data.

[0136] The fourth determination module is used to determine controller failure in response to an anomaly in at least one of the heartbeat data, communication data, and service data.

[0137] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0138] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0139] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0140] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0141] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as vehicle control methods. For example, in some embodiments, the vehicle control method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the vehicle control method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the vehicle control method by any other suitable means (e.g., by means of firmware).

[0142] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0143] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0144] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0145] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0146] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0147] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0148] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0149] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A vehicle control method, comprising: During vehicle operation, the vehicle control commands and vehicle planning paths generated by the vehicle's controller are acquired; In response to the detection of controller failure, a safety level is determined based on the vehicle's operating parameters, wherein the operating parameters include braking parameters, inertial measurement unit (IMU) parameters, and vehicle planned path parameters, and the safety level includes a first level, a second level, and a third level. Based on the safety level, a corresponding safety strategy is selected to control the vehicle to stop. The safety strategy includes a slow braking strategy based on the vehicle control command, a slow braking strategy based on the vehicle's planned path, and an emergency braking strategy based on wheel orientation. The step of determining the safety level based on the vehicle's operating parameters includes: In response to the operating parameters meeting a first condition, the safety level is determined to be level one, wherein the first condition is that the braking parameters, the inertial measurement unit (IMU) parameters, and the vehicle planning path parameters are all in a normal state; In response to the operating parameters meeting the second condition, the safety level is determined to be the second level, wherein the second condition is that both the braking parameters and the vehicle planning path parameters are in a normal state; In response to the operating parameters meeting a third condition, the security level is determined to be level three, wherein the third condition is any condition other than the first condition and the second condition.

2. The method according to claim 1, wherein, The safety levels of the first, second, and third levels are progressively downgraded; the step of selecting a corresponding safety strategy to control the vehicle to park based on the safety level includes: When the safety level is at the first level, a slow braking strategy based on the vehicle's planned path is selected to control the vehicle to stop. When the safety level is Level 2, a gentle braking strategy based on the vehicle control command is selected to control the vehicle to stop. When the safety level is level three, an emergency braking strategy based on wheel orientation is selected to control the vehicle to stop.

3. The method according to claim 2, further comprising: In response to a change in the vehicle's operating parameters, the safety level is downgraded based on the conditions met by the changed operating parameters. In response to the security level downgrade, the security policy is determined to be downgraded.

4. The method according to claim 3, wherein, The response to the security level downgrade, determining the security policy downgrade includes: In response to the safety level being downgraded from Level 1 to Level 2, the easing braking strategy based on the vehicle planning path is downgraded to the easing braking strategy based on the vehicle control command. In response to the safety level being downgraded from Level 1 to Level 3, the easing braking strategy based on the vehicle's planned path is downgraded to the emergency braking strategy based on wheel orientation. In response to the safety level being downgraded from Level 2 to Level 3, the easing braking strategy based on the vehicle control command is downgraded to the emergency braking strategy based on wheel orientation.

5. The method according to claim 1, wherein, The process of responding to a change in the vehicle's operating parameters and determining the safety level downgrade based on conditions met by the changed operating parameters includes: In response to the condition that the vehicle's operating parameters meet being downgraded from a first condition to a second condition, the safety level is determined to be downgraded from the first level to the second level. In response to the condition that the vehicle's operating parameters meet being downgraded from a first condition to a third condition, the safety level is determined to be downgraded from the first level to the third level. In response to the condition that the vehicle's operating parameters meet being downgraded from the second condition to the third condition, the safety level is determined to be downgraded from the second level to the third level.

6. The method according to claim 2, wherein, When the safety level is at the first level, selecting a gentle braking strategy based on the vehicle's planned path to control the vehicle to stop includes: Based on the actual operating environment of the vehicle, a correction instruction is generated to correct the planned path; Determine the correction path based on the correction instructions; The vehicle is controlled to stop according to the corrected path.

7. The method according to claim 2, wherein, The vehicle control command includes a sequence of control commands; the step of selecting a gentle braking strategy based on the vehicle control command to stop the vehicle when the safety level is level two includes: Based on the time point of controller failure, a control command at a specified time point is determined from the control command sequence as the starting command; The braking strategy based on vehicle control commands is executed starting from the first command in the sequence of control commands.

8. The method according to claim 1, further comprising: The status data of the controller is detected, including heartbeat data, communication data, and service data; The controller is determined to have failed in response to an anomaly occurring in at least one of the heartbeat data, communication data, and service data.

9. A vehicle control device, comprising: The acquisition module is used to acquire vehicle control commands and vehicle planned paths generated by the vehicle's controller during vehicle operation. The first determining module is configured to determine a safety level based on the vehicle's operating parameters in response to detecting a controller failure. The operating parameters include braking parameters, inertial measurement unit (IMU) parameters, and vehicle planning path parameters. The safety level includes a first level, a second level, and a third level. The control module is used to select a corresponding safety strategy to control the vehicle to stop according to the safety level. The safety strategy includes a slow braking strategy based on the vehicle control command, a slow braking strategy based on the vehicle's planned path, and an emergency braking strategy based on wheel orientation. The first determining module includes: The fourth determining unit is configured to determine the safety level as the first level in response to the operating parameters meeting the first condition, wherein the first condition is that the braking parameters, the inertial measurement unit (IMU) parameters, and the vehicle planning path parameters are all in a normal state; The fifth determining unit is configured to determine the safety level as the second level in response to the operating parameters meeting the second condition, wherein the second condition is that both the braking parameters and the vehicle planning path parameters are in a normal state; The sixth determining unit is configured to determine the security level as the third level in response to the operating parameters meeting the third condition, wherein the third condition is any condition other than the first condition and the second condition.

10. The apparatus according to claim 9, wherein, The security levels of the first, second, and third levels are progressively downgraded; the control module includes: The first control unit is configured to select a slow braking strategy based on the vehicle's planned path to control the vehicle to stop when the safety level is the first level. The second control unit is used to select a slack braking strategy based on the vehicle control command to control the vehicle to stop when the safety level is the second level. The third control unit is used to select an emergency braking strategy based on wheel orientation to control the vehicle to stop when the safety level is level three.

11. The apparatus of claim 10, further comprising: The second determining module is used to determine the safety level downgrade based on the conditions met by the changed operating parameters of the vehicle in response to a change in the vehicle's operating parameters. The third determining module is used to determine the security policy downgrade in response to the security level downgrade.

12. The apparatus according to claim 11, wherein, The third determining module includes: The first determining unit is configured to, in response to the safety level being downgraded from the first level to the second level, downgrade the easing braking strategy based on the vehicle planning path to the easing braking strategy based on the vehicle control command. The second determining unit is used to downgrade the easing braking strategy based on the vehicle planning path to the emergency braking strategy based on wheel orientation in response to the downgrading of the safety level from the first level to the third level. The third determining unit is configured to, in response to the safety level being downgraded from the second level to the third level, downgrade the easing braking strategy based on the vehicle control command to the emergency braking strategy based on wheel orientation.

13. The apparatus according to claim 11, wherein, The second determining module includes: The seventh determining unit is configured to determine that the safety level is downgraded from the first level to the second level in response to the condition that the operating parameters of the vehicle meet being downgraded from the first condition to the second condition. The eighth determining unit is configured to determine that the safety level is downgraded from the first level to the third level in response to the condition that the operating parameters of the vehicle meet being downgraded from the first condition to the third condition. The ninth determining unit is configured to determine that the safety level is downgraded from the second level to the third level in response to the condition that the operating parameters of the vehicle meet being downgraded from the second condition to the third condition.

14. The apparatus according to claim 10, wherein, The first control unit includes: A generation subunit is used to generate correction instructions for correcting the planned path based on the actual operating environment of the vehicle. The correction subunit is used to determine the correction path according to the correction instruction; A control subunit is used to control the vehicle to stop according to the corrected path.

15. The apparatus according to claim 10, wherein, The vehicle control commands include a sequence of control commands; The second control unit includes: A determining subunit is used to determine, based on the time point of controller failure, a control command at a specified time point from the control command sequence as the starting command; An execution subunit is used to execute a braking strategy based on vehicle control commands, starting from the initial command in the sequence of control commands.

16. The apparatus of claim 9, further comprising: The detection module is used to detect the status data of the controller, including heartbeat data, communication data, and service data. The fourth determination module is used to determine that the controller has failed in response to an anomaly occurring in at least one of the heartbeat data, communication data, and service data.

17. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 8.

18. An autonomous vehicle, including the electronic equipment as claimed in claim 17.

19. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 8.

20. A computer program product comprising a computer program stored on at least one of a readable storage medium and an electronic device, the computer program implementing the method according to any one of claims 1 to 8 when executed by a processor.

Images