A kind of method, device and storage medium of parking control

Abstract

This application discloses a parking control method, device, and storage medium to shorten the time required for parking switching. After the vehicle is powered on, the first controller controls the vehicle to start parking mode. When it is determined that the parking function corresponding to the parking mode is inactive, the controller determines whether the vehicle is in a pre-marked target area based on the received first current map location information. If the vehicle is not in the target area, the controller obtains the vehicle's current speed. If the current speed is greater than a first preset speed, the controller controls the vehicle to start driving mode. This application combines map information and vehicle speed to comprehensively determine whether to switch between parking and driving modes. This allows the switching process to be completed before the user actually activates the parking function, shortening the waiting time when the user triggers the parking function and improving the function's response speed and usability.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a parking control method, device and storage medium. Background Technology

[0002] In the integrated driving and parking intelligent driving solution of related technologies, the switching between driving mode and parking mode mainly relies on user-initiated activation. The vehicle system is in driving mode by default, and the system only switches from driving mode to parking mode when the user actively clicks the parking activation button; when the user exits the parking function, the system switches back from parking mode to driving mode.

[0003] The above-mentioned method, which relies on the user to actively trigger the parking switch, has the following technical problems: the parking switch only starts after the user's operation, resulting in a long switching time. Users must wait for the switch to complete before they can use the parking function, which causes a delay. At the same time, the switching logic is relatively rigid, which affects the user experience. Summary of the Invention

[0004] In view of this, this application provides a berthing control method, device and storage medium to shorten the time of berthing switching process, improve the flexibility of berthing switching and enhance user experience.

[0005] In a first aspect, embodiments of this application provide a parking control method applied to a first controller, the method comprising: In response to the vehicle's power-on command, the vehicle is controlled to start the parking mode; when it is determined that the parking function corresponding to the parking mode is inactive, the vehicle is determined to be in a pre-marked target area based on the received first current map location information; when the vehicle is not in the target area, the vehicle's current speed is obtained; if it is determined that the current speed is greater than the first preset speed, the vehicle is controlled to start the driving mode.

[0006] In this embodiment, by combining map information and the vehicle's current speed to determine whether to switch between driving and parking modes, the mode switching process can be completed before the user actually activates the driving and parking function. This significantly shortens the waiting time when the user triggers the driving and parking function, improving the function's response speed and smoothness of use. Simultaneously, the vehicle can automatically switch to parking mode when it enters a suitable parking area, eliminating the need for manual triggering by the user. This effectively simplifies the user's operation steps, enhances the convenience, ease of use, and flexibility of the intelligent driving function, and optimizes the overall user experience.

[0007] In some possible embodiments, the method further includes: when the vehicle is in the target area, generating a first prompt in response to a user-triggered driving activation command, the first prompt being used to inform the user that it is not recommended to enable driving functions in the current area.

[0008] In this embodiment of the application, a first prompt is generated to inform the user that the current location is not suitable for activating the driving function, thereby avoiding safety risks caused by accidental activation of the driving mode.

[0009] In some possible embodiments, when the vehicle is in the target area, a first prompt is generated in response to a user-triggered driving activation command, including: if the duration of the vehicle being in the target area is longer than a first preset duration, the first prompt is generated in response to a user-triggered driving activation command.

[0010] In this embodiment of the application, when the duration of a vehicle in the target area is longer than a first preset duration, it indicates that the vehicle is not passing through quickly, but rather intends to stop. This means that the vehicle is likely to have a parking need, providing a further basis for determining whether to switch between driving and parking.

[0011] In some possible embodiments, after generating a first prompt in response to a user-triggered vehicle activation command, the method further includes: if a user-triggered vehicle activation command is detected within a second preset time period after the first prompt is generated, then controlling the vehicle to start a driving mode.

[0012] In this embodiment of the application, if the driving activation command is detected again, it indicates that the user did not operate by mistake, but actually has a driving need. In order to meet the user's actual needs, the vehicle is controlled to start the driving mode.

[0013] In some possible embodiments, after controlling the vehicle to start a driving mode, the method further includes: when it is determined that the driving function corresponding to the driving mode is inactive, determining whether the vehicle is in a pre-marked target area based on the received second current map location information; when the vehicle is in the target area, controlling the vehicle to start a parking mode.

[0014] In this embodiment of the application, when it is determined that the vehicle is in the pre-marked target area, it can be confirmed that the vehicle is currently in the parking lot. Therefore, the vehicle is controlled to start the parking mode to shorten the time of the parking switch process.

[0015] In some possible embodiments, after controlling the vehicle to start the parking mode, the method further includes: determining available parking spaces based on second current map location information; the available parking spaces are used for parking when the user starts the parking function.

[0016] In this embodiment, when the vehicle switches from driving mode to parking mode, a parking space search is performed. When an available parking space is found, a pop-up window prompts the user to use the automatic parking function. If the user clicks the parking activation button and enters the parking page, they can immediately see the parking space information that has been successfully searched, thus improving parking efficiency and intelligence.

[0017] In some possible embodiments, the method further includes: when the vehicle is not in the target area, generating a second prompt in response to a parking activation command triggered by the user, the second prompt informing the user that it is not recommended to activate the parking function in the current area.

[0018] In this embodiment of the application, when the vehicle is in a location unsuitable for parking, a second prompt is generated to inform the user that the current location is not suitable for activating the parking function, thereby avoiding safety risks caused by accidental activation of the parking mode.

[0019] In some possible embodiments, the method further includes: when the vehicle is not in the target area, obtaining the vehicle's current speed in response to a parking activation command triggered by the user; if it is determined that the current speed is less than a second preset speed, controlling the vehicle to start a parking mode.

[0020] In this embodiment of the application, when it is determined that the user has a parking need, in order to ensure the driving safety of the vehicle during the parking process and mode switching process, the vehicle speed must be judged before executing the parking mode switching and starting the parking function to ensure the safety of the parking operation.

[0021] In some possible embodiments, the method further includes: if it is determined that the current vehicle speed is greater than or equal to a second preset vehicle speed, generating a third prompt, the third prompt being used to inform the user to reduce the vehicle speed in order to switch modes.

[0022] In this embodiment of the application, a third prompt is generated and output to remind the user to reduce the vehicle speed in time so that the vehicle meets the speed requirements for entering the parking mode, thereby smoothly executing the subsequent mode switch.

[0023] In some possible embodiments, after controlling the vehicle to start driving mode, the method further includes: sending a first parking switch command to a second controller, the first parking switch command being used to instruct the vehicle to switch from parking mode to driving mode.

[0024] In some possible embodiments, after controlling the vehicle to start parking mode, the method further includes: sending a second driving / parking switching command to a second controller, the second driving / parking switching command being used to instruct the vehicle to switch from driving mode to parking mode.

[0025] Secondly, embodiments of this application provide a parking control method applied to a second controller. The method includes: receiving a parking switching command sent by a first controller; determining that the vehicle is in a first state according to the parking switching command; if the parking switching command is a first parking switching command, then the first state is a driving state; if the parking switching command is a second parking switching command, then the first state is a parking state; stopping the execution of commands related to the second state and stopping the reporting of faults related to the second state; if the parking switching command is a first parking switching command, then the second state is a parking state; if the parking switching command is a second parking switching command, then the second state is a driving state.

[0026] Thirdly, embodiments of this application provide a berthing control device applied to a first controller, the device comprising: The response module is used to respond to the vehicle's power-on command and control the vehicle to start the parking mode. The receiving module is used to determine whether the vehicle is in a pre-marked target area based on the received first current map location information when the parking function corresponding to the parking mode is inactive. The vehicle speed acquisition module is used to acquire the vehicle's current speed when the vehicle is not in the target area; The mode switching module is used to control the vehicle to start the driving mode if it is determined that the current vehicle speed is greater than the first preset vehicle speed.

[0027] In some possible embodiments, the receiving module is further configured to: when the vehicle is in the target area, generate a first prompt in response to a user-triggered driving activation command, the first prompt being used to inform the user that it is not recommended to enable driving functions in the current area.

[0028] In some possible embodiments, the receiving module is specifically configured to: if the duration of the vehicle's stay in the target area is greater than a first preset duration, generate a first prompt in response to a user-triggered driving activation command, provided that the vehicle is in the target area.

[0029] In some possible embodiments, the receiving module is further configured to: if a user-triggered driving activation command is detected within a second preset time period after the first prompt is generated, control the vehicle to start driving mode.

[0030] In some possible embodiments, the mode switching module is further configured to: determine whether the vehicle is in a pre-marked target area based on the received second current map location information when the driving function corresponding to the driving mode is inactive; and control the vehicle to start the parking mode when the vehicle is in the target area.

[0031] In some possible embodiments, the mode switching module is further configured to: determine available parking spaces based on the second current map location information; the available parking spaces are used for parking when the user activates the parking function.

[0032] In some possible embodiments, the mode switching module is further configured to: generate a second prompt in response to a parking activation command triggered by the user when the vehicle is not in the target area, the second prompt being used to inform the user that it is not recommended to activate the parking function in the current area.

[0033] In some possible embodiments, the mode switching module is further configured to: when the vehicle is not in the target area, obtain the current speed of the vehicle in response to a parking activation command triggered by the user; if it is determined that the current speed is less than a second preset speed, control the vehicle to start the parking mode.

[0034] In some possible embodiments, the vehicle speed acquisition module is further configured to: if it is determined that the current vehicle speed is greater than or equal to a second preset vehicle speed, generate a third prompt, the third prompt being used to inform the user to reduce the vehicle speed in order to switch modes.

[0035] In some possible embodiments, the mode switching module is further configured to: send a first parking switch command to the second controller, the first parking switch command being used to instruct the vehicle to switch from parking mode to driving mode.

[0036] In some possible embodiments, the mode switching module is further configured to: send a second driving / parking switching command to the second controller, the second driving / parking switching command being used to instruct the vehicle to switch from driving mode to parking mode.

[0037] Fourthly, embodiments of this application provide a berthing control device applied to a second controller, the device comprising: The instruction receiving module is used to receive the line-and-boat switching instruction sent by the first controller; The state determination module is used to determine the vehicle's first state based on the driving and parking switching command; if the driving and parking switching command is the first driving and parking switching command, the first state is the driving state; if the driving and parking switching command is the second driving and parking switching command, the first state is the parking state. The control module is used to stop executing instructions related to the second state and stop reporting faults related to the second state; if the parking switch instruction is the first parking switch instruction, the second state is the parking state; if the parking switch instruction is the second parking switch instruction, the second state is the driving state.

[0038] Fifthly, another embodiment of this application also provides an electronic device, including 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 any of the methods provided in the first and second aspects of this application.

[0039] Sixthly, another embodiment of this application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for causing a computer to perform any of the methods provided in the first and second aspects of the embodiments of this application.

[0040] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This application provides a schematic diagram of the berth's operating state in the relevant art for the embodiments of this application; Figure 2 A schematic diagram of the system framework of a berthing control method provided in this application embodiment; Figure 3 This is a schematic diagram of the overall process of a berthing control method provided in an embodiment of this application; Figure 4 This is a first schematic diagram illustrating a berthing control method provided in an embodiment of this application; Figure 5 A schematic diagram illustrating the process of switching driving mode to parking mode in a driving and parking control method provided in this application embodiment; Figure 6 This is a second schematic diagram illustrating a berthing control method provided in an embodiment of this application; Figure 7 A third schematic diagram illustrating a berthing control method provided in an embodiment of this application; Figure 8 A schematic diagram illustrating the interaction flow between the SOC and MCU in a berthing control method provided in this application embodiment; Figure 9 A schematic diagram of an Ethernet interface for a berthing control method provided in an embodiment of this application; Figure 10 A schematic diagram of an apparatus for a berthing control method provided in an embodiment of this application; Figure 11 This is a schematic diagram of another apparatus for a berthing control method provided in an embodiment of this application; Figure 12 This is a schematic diagram of an electronic device for a berthing control method provided in an embodiment of this application. Detailed Implementation

[0043] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0044] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0045] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0046] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0047] Intelligent driving technology has become an important direction for the development of the modern automotive industry. As the technology in the field of intelligent driving continues to mature and market competition intensifies, more and more mass-produced models are equipped with intelligent driving-related solutions. For mid-to-low-end models, under the premise of comprehensively considering cost and product competitiveness, low-computing-power, low-cost single-chip systems are often used as system-on-chips (SOCs). The computing power of the SOC is time-sharing multiplexed through driving and parking switching to meet the requirements of L2-level driving and parking integrated intelligent driving functions.

[0048] Due to the limited computing power of this type of chip, it is impossible to run both driving and parking algorithm models and their corresponding processes in parallel. It can only support the operation of a single function model at any given time. Therefore, the system divides the SOC into two working states: driving mode and parking mode. In driving mode, only driving-related functions can be enabled, and in parking mode, only parking-related functions can be enabled. The system switches between the two modes according to usage needs, i.e., driving-parking switching. By running driving or parking functions in a time-sharing manner, a system-level integrated driving and parking experience is achieved.

[0049] To achieve basic integrated driving and parking functions, the main functions of driving mode and parking mode in the SOC and MCU are as follows: Figure 1 As shown, this type of solution typically uses a 5R5V12U sensor configuration, including 5 cameras (1 forward-facing camera for driving functions and 4 fisheye cameras for parking functions), 5 millimeter-wave radars (for Lane Centering Control (LCC) and automatic lane changing functions), and 12 ultrasonic radars (for parking functions). In driving mode, the domain controller only accesses and processes data from the forward-facing camera and millimeter-wave radar; in parking mode, the domain controller only accesses and processes data from the fisheye camera and ultrasonic radar. The millimeter-wave radar and ultrasonic radar data are connected to the microcontroller unit (MCU) via the Controller Area Network (CAN) bus, while the camera data is connected to the domain controller SOC via a Low-Voltage Differential Signaling (LVDS) interface.

[0050] The above-mentioned method, which relies on the user to actively trigger the parking switch, has the following technical problems: the parking switch only starts after the user operates, resulting in a long switching time. Users must wait for the switch to complete before they can use the parking function, which causes a delay. At the same time, the switching logic is relatively rigid and is prone to unnecessary repeated switching due to accidental touches or short-term multiple use needs, which affects the user experience.

[0051] To address the aforementioned problems, this application provides a parking control method, device, and storage medium to solve these issues. The inventive concept of this application can be summarized as follows: After the vehicle is powered on, a first controller in the vehicle controls the vehicle to start a parking mode; when it is determined that the vehicle's parking function is inactive, it determines whether the vehicle is in a pre-marked target area based on received first current map location information; if the vehicle is not in the target area, it obtains the vehicle's current speed; if it is determined that the current speed is greater than a first preset speed, it controls the vehicle to start a driving mode.

[0052] In this embodiment, by combining map information and the vehicle's current speed to determine whether to switch between driving and parking modes, the system can complete the mode switching process before the user actually activates the parking function. This significantly shortens the waiting time when the user triggers the parking function, improving the function's response speed and smoothness of use. Simultaneously, the system can automatically switch to parking mode when the vehicle enters a suitable parking area and automatically switch from parking mode to driving mode when the vehicle is in a suitable driving area, eliminating the need for manual user intervention. This effectively simplifies user operations, enhances the convenience and ease of use of intelligent driving functions, and optimizes the overall user experience.

[0053] For ease of understanding, the following detailed description of a berthing control method provided by an embodiment of this application, in conjunction with the accompanying drawings, will be provided: Based on the above system architecture, the following describes a berthing control method provided by an embodiment of this application, such as... Figure 2 The diagram shown is an overall flowchart of a berthing control method provided in this application embodiment when the execution subject is a first controller, wherein: In step 201: In response to the vehicle's power-on command, control the vehicle to start the parking mode.

[0054] In this embodiment of the application, considering that the vehicle is mostly stationary or in a low-speed parking scenario during the initial stage of power-on, the vehicle defaults to parking mode after power-on. The system prioritizes entering the parking-related function ready state, prioritizes loading and enabling parking mode-related modules, and keeps driving mode-related modules in an inactive or standby state.

[0055] In step 202: when it is determined that the parking function corresponding to the parking mode is inactive, it is determined whether the vehicle is in the pre-marked target area based on the received first current map location information; if it is determined that the vehicle is in the pre-marked target area, proceed to step 203, otherwise proceed to step 207.

[0056] In this embodiment, enclosed areas such as residential communities, public parking lots, shopping malls, and factories that can meet parking needs are pre-marked on maps. By obtaining the vehicle's current map location information, the vehicle's real-time location is compared with the pre-marked area range to determine whether the vehicle is located within the pre-marked target area. When it is determined that the vehicle is within the pre-marked target area, it can be confirmed that the vehicle is currently in the parking lot; otherwise, it can be confirmed that the vehicle is currently in the driving area, providing a scenario judgment basis for determining whether a driving-parking switch is needed.

[0057] In step 203: determine whether the duration of the vehicle being in the target area is greater than the first preset duration; if so, proceed to step 204, otherwise proceed to step 207.

[0058] In this embodiment, when a vehicle is within a pre-marked target area, it only indicates that the vehicle is currently within a suitable parking area; it cannot distinguish whether the vehicle is planning to park or is merely temporarily passing through the area. To avoid erroneously triggering parking-related logic due to a vehicle momentarily passing through the parking area, it is necessary to further detect and determine the duration of the vehicle's stay within the target area. When the duration of the vehicle's stay within the target area exceeds a first preset duration, it indicates that the vehicle is not passing through quickly but rather intends to stay, thus determining that the vehicle likely has a parking need, providing further criterion for switching between driving and parking.

[0059] For example, the first preset duration can be set to 3 seconds or 5 seconds. This application does not limit the specific value of the first preset duration. In specific implementation, the specific value of the first preset duration can be set according to the needs.

[0060] It should be noted that this step is optional. After completing step 202 and determining that the vehicle is in the pre-marked target area, you can directly proceed to step 204 without having to perform the judgment step in step 203.

[0061] In step 204: A first prompt is generated in response to the user-triggered driving activation command. The first prompt is used to inform the user that it is not recommended to enable driving functions in the current area.

[0062] In this embodiment, when the vehicle is in a parking lot, if the user has a driving need and triggers the driving activation command through the driving button on the vehicle, considering that the parking lot is a relatively enclosed space with complex road conditions and is mainly used for parking and low-speed vehicle movement, it is not suitable to directly activate the driving mode. Therefore, a first prompt can be generated to inform the user that the current location is not suitable for activating the driving function, so as to avoid safety risks caused by accidental activation of the driving mode.

[0063] For example: Figure 3 As shown, the vehicle's in-vehicle display screen shows the first prompt: "The current location is not suitable for activating driving functions. Please confirm again whether you need to enter driving mode."

[0064] In step 205: Determine whether a user-triggered vehicle activation command is detected within a second preset time period after the first prompt is generated. If yes, proceed to step 206; otherwise, proceed to step 207.

[0065] In this embodiment, if a driving activation command triggered by the user via the driving button on the vehicle is detected again within a second preset time period after the first prompt is generated and displayed, it indicates that the user's operation was not accidental, but rather a genuine driving need, and a desire to use the driving function within the current location. In this case, to meet the user's actual needs, the vehicle needs to be controlled to activate the driving mode, providing the user with corresponding driving assistance functions. If no driving activation command is detected again within the second preset time period, it is determined that the user's previous operation was accidental, and therefore the vehicle's current parking mode will remain unchanged to avoid accidental mode switching due to misoperation.

[0066] It should be noted that this step is optional. After completing step 204 and confirming that the user has triggered the driving activation command through the driving button set on the vehicle, you can directly proceed to step 206 without having to execute step 205.

[0067] In step 206: Control the vehicle to start driving mode.

[0068] In this embodiment, through the multiple judgment logic set above, when the user has a clear and real driving need, the vehicle working mode can be switched from parking mode to driving mode in a timely manner, without the user having to wait or repeat the operation. This effectively shortens the response time for the user to activate the driving function and improves the convenience of using the function and the user experience.

[0069] In step 207: Obtain the vehicle's current speed.

[0070] In this embodiment, when the vehicle is not within the pre-marked target area, it indicates that the vehicle is not currently within a suitable parking area. At this point, the vehicle's current speed can be used to determine if the vehicle has a driving need. If it is determined that the vehicle has a driving need, the vehicle's operating mode is automatically switched from parking mode to driving mode. This process can be completed automatically without manual user operation, effectively shortening the response time for the user to activate the driving function and improving the convenience and user experience of the function.

[0071] In step 208: Determine whether the current vehicle speed is greater than the first preset vehicle speed. If the current vehicle speed is greater than the first preset vehicle speed, proceed to step 209; otherwise, return to step 202.

[0072] In this embodiment, when the vehicle's current speed is greater than a first preset speed, it indicates that the vehicle is in motion and the user intends to drive. Based on this, it can be determined that the user has a driving need, and the vehicle's working mode is automatically switched from parking mode to driving mode without the user having to manually trigger the operation, thereby shortening the activation response time of the driving function and improving the ease of use of the system.

[0073] In step 209: Control the vehicle to start driving mode.

[0074] In this embodiment, through the multiple judgment logic set above, when the user has a clear and real driving need, the vehicle working mode can be switched from parking mode to driving mode in a timely manner, without the user having to wait or repeat the operation. This effectively shortens the response time for the user to activate the driving function and improves the convenience of using the function and the user experience.

[0075] In response to the above Figure 2 It should be noted that the above process can be executed not only when the vehicle is powered on, but also when the vehicle is in parking mode. Figure 2 The process shown is used to determine whether there is a need for driving, so as to control the vehicle to start the driving mode in a timely manner.

[0076] In some possible embodiments, when the vehicle is in driving mode, it can be achieved through, for example... Figure 4 The process shown is to determine whether the user intends to park, wherein: In step 401: Determine whether the driving function corresponding to the driving mode is active; if the vehicle's driving function is active, proceed to step 402, otherwise proceed to step 403.

[0077] In this embodiment, when the vehicle's driving functions are active, it indicates that the user is currently using driving-related assistance functions, and the vehicle is in normal driving condition. Therefore, the vehicle can continue to operate in driving mode without needing to switch modes. When the vehicle's driving functions are not active, it indicates that the vehicle is not currently using driving assistance functions, and the vehicle may be about to enter a parking space or preparing to park. In this case, the system can perform a switching operation from driving mode to parking mode by subsequent judgment processes, when it detects that the user intends to park or that the vehicle meets the parking scenario conditions.

[0078] In step 402: Maintain the current driving mode.

[0079] In this embodiment, when the user is using driving-related assistance functions and the vehicle is in normal driving conditions, the vehicle continues to operate in driving mode without the need for mode switching.

[0080] In step 403: Determine whether the vehicle is in the pre-marked target area based on the received second current map location information; if the vehicle is not in the pre-marked target area, proceed to step 404, otherwise proceed to step 409.

[0081] The specific implementation method of this step is the same as that of step 202 above, and will not be repeated here.

[0082] In step 404: Is a parking activation command triggered by the user detected? If a parking activation command triggered by the user is detected, proceed to step 405; otherwise, proceed to step 402.

[0083] In this embodiment, when the vehicle is not within the pre-marked target area, it indicates that the area where the vehicle is currently located is not a preset dedicated parking space. Even so, if the user actively triggers a parking activation command, it can be determined that the user has a genuine parking need, and the subsequent parking mode-related processing flow can be entered accordingly; otherwise, the current driving mode can continue to be maintained.

[0084] In step 405: A second prompt is generated, which informs the user that it is not recommended to enable the parking function in the current area.

[0085] In this embodiment of the application, when the vehicle is in a location unsuitable for parking, a second prompt is generated to indicate that the current location is not suitable for activating the parking function, thereby avoiding safety risks caused by accidental activation of the parking mode.

[0086] For example: Figure 5 As shown, a second prompt is displayed on the vehicle's in-vehicle display screen: "The current location is not suitable for activating the parking function. Please confirm again whether you need to enter parking mode."

[0087] In step 406: Determine whether a parking activation command triggered by the user is detected within a third preset time period after the second prompt is generated. If yes, proceed to step 407; otherwise, proceed to step 402.

[0088] In this embodiment, if a parking activation command triggered by the user via the parking button on the vehicle is detected again within a third preset time period after the second prompt is generated and displayed, it indicates that the user's operation was not accidental, but rather that they genuinely need to park and wish to use the parking function in the current location. In this case, to meet the user's actual needs, the vehicle needs to be controlled to activate the parking mode, providing the user with the corresponding parking assistance function. If no parking activation command triggered by the user is detected again within the third preset time period, it is determined that the user's previous operation was accidental, and therefore the vehicle's current driving mode will remain unchanged to avoid accidental mode switching due to misoperation.

[0089] In step 407: Obtain the vehicle's current speed.

[0090] In step 408: Determine whether the current vehicle speed is greater than or equal to the second preset vehicle speed. If the current vehicle speed is greater than or equal to the second preset vehicle speed, proceed to step 409; otherwise, proceed to step 410.

[0091] In this embodiment, when a user is determined to have a parking need, to ensure vehicle safety during the parking process and mode switching, it is necessary to determine whether the vehicle's current speed is greater than or equal to a second preset speed before performing parking mode switching and activating the parking function. If the vehicle's current speed is greater than or equal to the second preset speed, it indicates that the vehicle is traveling at a relatively high speed. Performing mode switching or activating parking at this time could pose a safety hazard and does not meet the speed requirements for the parking scenario; therefore, mode switching is not permitted.

[0092] In step 409: A third prompt is generated, which is used to inform the user to reduce the vehicle speed in order to switch modes.

[0093] In this embodiment of the application, a third prompt is generated and output to remind the user to reduce the vehicle speed in time so that the vehicle meets the speed requirements for entering the parking mode, thereby smoothly executing the subsequent mode switch.

[0094] For example: Figure 6 As shown, a third prompt is displayed on the vehicle's in-vehicle display screen: "Please reduce your speed to ensure a smooth parking experience."

[0095] In step 410: when the vehicle's current speed is detected to be less than the second preset speed, the vehicle is controlled to start parking mode.

[0096] In this embodiment, when the vehicle's current speed is detected to be less than a second preset speed, it indicates that the vehicle has met the conditions for safely switching to parking mode, and the vehicle is immediately controlled to activate parking mode. This method can quickly respond to parking needs while meeting safety conditions, effectively shortening the waiting and response time for users to activate the parking function, and improving the convenience of using the function and the overall user experience.

[0097] In step 411: Available parking spaces are determined based on the second current map location information; available parking spaces are used to park the car when the user activates the parking function.

[0098] In this embodiment, when the vehicle switches from driving mode to parking mode, the data monitoring of parking-related processes in both the first and second controllers is running, thus continuously processing the data from the fisheye camera and ultrasonic radar. When the user drives the vehicle past a parking space, even if the user does not click the parking button, a parking space search can be performed based on the data from the fisheye camera and ultrasonic radar. When an available parking space is found, a pop-up window prompts the user to use the automatic parking function. If the user clicks the parking activation button and enters the parking page, they can immediately see the successfully searched parking space information, thus improving parking efficiency and intelligence.

[0099] For example, the first controller can be a SoC and the second controller can be an MCU.

[0100] In some possible embodiments, to ensure the smooth operation of the docking switchover process, the first controller and the second controller in the system framework can perform actions such as... Figure 7 The interaction flow shown is as follows: In step 701: The intelligent cockpit obtains the vehicle's current map location information.

[0101] In this embodiment of the application, the intelligent cockpit receives satellite positioning signals and auxiliary information such as vehicle attitude and wheel speed through the vehicle positioning module, calculates the real-time geographic coordinates of the vehicle, and performs coordinate correction and road matching in combination with the vehicle electronic map data, thereby obtaining the current map location information of the vehicle.

[0102] In step 702: The intelligent cockpit sends the current map location information to the first controller.

[0103] In this embodiment of the application, the intelligent cockpit can send the acquired current map location information to the first controller in real time via an Ethernet link.

[0104] In some possible embodiments, given the limited computing resources of the intelligent driving first controller chip in parking switching scenarios, to simplify interface design, reduce data interaction volume, improve data processing efficiency, and reduce timing overhead caused by new interfaces, relevant information exchanged between the original intelligent cockpit and intelligent driving domain via CAN bus is uniformly migrated to a newly added Ethernet interface for transmission, eliminating the original CAN communication link. This approach optimizes the inter-domain communication architecture of the entire vehicle, improves overall data interaction efficiency, and reduces hardware link configuration, effectively lowering system costs.

[0105] Example: Adding a new Ethernet interface, such as Figure 8 As shown, the current map location information, driving button, and parking button are all migrated to the newly added Ethernet interface. Different enumeration values ​​are set for different data so that the first controller can determine the specific data information based on the received enumeration values.

[0106] In step 703: the first controller receives the current map location information sent by the smart cockpit.

[0107] In this embodiment of the application, the first controller receives the current map location information sent by the smart cockpit based on the newly added Ethernet interface.

[0108] The vehicle switches from driving mode to parking mode: In step 704: The first controller determines that the parking mode needs to be activated.

[0109] The specific implementation method of this step is the same as described above. Figure 4The process shown is the same, so it will not be repeated here.

[0110] In step 705: the first controller sends a first line-stop switching command to the second controller.

[0111] In this embodiment of the application, the first driving / parking switching command instructs the vehicle to switch from driving mode to parking mode.

[0112] In step 706: the second controller stops data monitoring and error handling of processes related to the driving mode.

[0113] In this embodiment, when the vehicle switches from driving mode to parking mode, it is not necessary to shut down the processes related to driving mode in the second controller; only the reporting process of the corresponding fault information needs to be masked. This method avoids time-consuming operations such as process restart and initialization, shortens the system switching response time, and keeps the second controller in a ready state, thereby enabling it to quickly respond to subsequent driving-parking switching operations.

[0114] In step 707: The first controller disables data monitoring and error handling related to the driving mode.

[0115] In this embodiment, after the vehicle switches from driving mode to parking mode, it is prone to false fault reports due to the change in working mode and operating conditions. To avoid such false alarms, the first controller needs to disable the corresponding data monitoring, fault reporting, and diagnostic processing procedures in driving mode after the mode switch is completed, thereby ensuring the stable operation of the system in parking mode and preventing the generation of invalid fault information.

[0116] In step 708: the first controller closes the forward-looking camera data channel and opens the fisheye camera data channel.

[0117] In this embodiment, when the vehicle driving and parking modes are switched, the first controller closes the data transmission channel corresponding to the forward-looking camera and opens the data transmission channel corresponding to the fisheye camera. By switching the access data sources of different cameras, it ensures that the environmental perception data obtained by the system during the driving and parking switching process matches the current operating conditions, thereby ensuring that the image data received by the first controller is accurate and reliable, and providing stable and effective data support for driving and parking control.

[0118] In step 709: The first controller starts monitoring and handling error reports related to the parking mode.

[0119] In this embodiment, after the vehicle switches to parking mode, the first controller initiates a data monitoring and fault diagnosis reporting process that matches the parking mode. This enables real-time and effective monitoring of the operating status of each module under parking conditions, timely identification and accurate reporting of various faults that occur during operation, and improves the reliability of system operation and the timeliness of fault response in parking mode.

[0120] In step 710: the first controller sends a parking process start command to the second controller.

[0121] In this embodiment, the parking process start instruction is used to inform the second controller to enable data monitoring and error reporting for the parking mode-related processes.

[0122] In step 711: The second controller starts data monitoring and error reporting for the parking mode-related processes based on the parking process start command.

[0123] In this embodiment, after the vehicle switches to parking mode, the second controller initiates a data monitoring and fault diagnosis reporting process that matches the parking mode. This enables real-time and effective monitoring of the operating status of each module under parking conditions, timely identification and accurate reporting of various faults that occur during operation, and improves the reliability of system operation and the timeliness of fault response in parking mode.

[0124] The vehicle switches from parking mode to driving mode: In step 712: the first controller determines to start the driving mode.

[0125] The specific implementation method of this step is the same as described above. Figure 2 The process shown is the same, so it will not be repeated here.

[0126] In step 713: the first controller sends a second row dock switching command to the second controller. In this embodiment of the application, the second parking switch command instructs the vehicle to switch from parking mode to driving mode.

[0127] In step 714: the second controller stops data monitoring and error handling related processes of parking mode.

[0128] In this embodiment, when the vehicle switches from parking mode to driving mode, it is not necessary to shut down the processes related to parking mode in the second controller; only the reporting process of the corresponding fault information needs to be masked. This method avoids time-consuming operations such as process restart and initialization, shortens the system switching response time, and keeps the second controller in a ready state, thereby enabling it to quickly respond to subsequent parking-driving switching operations.

[0129] In step 715: The first controller disables data monitoring and error handling related to parking mode.

[0130] In this embodiment, after the vehicle switches from parking mode to driving mode, it is prone to false fault reports due to the change in working mode and operating conditions. To avoid such false alarms, the first controller needs to disable the corresponding data monitoring, fault reporting, and diagnostic processing flow in parking mode after the mode switch is completed, thereby ensuring the stable operation of the system in driving mode and preventing the generation of invalid fault information.

[0131] In step 716: The first controller closes the fisheye camera data channel and opens the front-view camera data channel.

[0132] In this embodiment, when the vehicle driving and parking modes are switched, the first controller closes the data transmission channel corresponding to the fisheye camera and opens the data transmission channel corresponding to the front-view camera. By switching the access to different camera data sources, it ensures that the environmental perception data acquired by the system during the driving and parking switching process matches the current operating conditions, thereby ensuring that the image data received by the first controller is accurate and reliable, and providing stable and effective data support for driving and parking control.

[0133] In step 717: The first controller starts data monitoring and error handling related to the driving mode.

[0134] In this embodiment, after the vehicle switches to driving mode, the first controller starts a data monitoring and fault diagnosis reporting process that matches the driving mode. This process can monitor the operating status of each module in real time and effectively, identify and accurately report various faults that occur during operation, and improve the reliability of the system operation and the timeliness of fault response in driving mode.

[0135] In step 718: the first controller sends a vehicle operation start command to the second controller.

[0136] In this embodiment, the driving process start instruction is used to inform the second controller to enable data monitoring and error reporting for the driving mode-related processes.

[0137] In step 719: The second controller starts data monitoring and error reporting for the driving mode-related processes based on the driving process start command.

[0138] In this embodiment, after the vehicle switches to driving mode, the second controller starts a data monitoring and fault diagnosis reporting process that matches the driving mode. This process can monitor the operating status of each module in real time and effectively, identify and accurately report various faults that occur during operation, and improve the reliability of the system operation and the timeliness of fault response in driving mode.

[0139] Taking a first controller as a SOC and a second controller as a MUC as an example, the system architecture diagram corresponding to a berthing control method provided in this application is illustrated below. Figure 9 As shown, the system architecture includes a SOC and an MCU. The SOC and MCU will be described in detail below: First, let's explain the SOC. The SOC is a chip within the intelligent driving domain controller, used to respond to user-triggered parking switching commands based on the intelligent cockpit and to complete the parking switching action accordingly. It also receives camera data. The SOC includes: a forward-looking perception module, a forward-looking perception post-processing module, a fisheye perception module, a fisheye perception post-processing module, a fisheye ultrasonic fusion module, a parking planning module, a SOC parking state machine, and other SOC process modules. Among these: The forward perception module is used to receive and parse image data transmitted by the forward-facing camera through the LVDS interface, and to perform environmental perception tasks in driving mode, including lane line detection, traffic participant recognition, obstacle detection, and traffic sign recognition.

[0140] The forward perception post-processing module is used to perform data verification, anomaly filtering, spatiotemporal alignment, and result fusion on the target detection and scene recognition results output by the forward perception module, providing stable and reliable environmental perception input information for Advanced Driver Assistance Systems (ADAS).

[0141] The fisheye perception module is used to receive and parse wide-angle image data transmitted by the surround-view fisheye camera through the LVDS interface, and extract the outline of the environment around the vehicle and detect the location information of available parking spaces and surrounding obstacles in parking mode.

[0142] The fisheye perception post-processing module is used to perform distortion correction, image stitching, color restoration, and target denoising on the wide-angle image output by the fisheye perception module, generating a high-precision, distortion-free panoramic top-down view to improve the accuracy of parking environment perception.

[0143] The fisheye ultrasonic fusion module is used to perform spatiotemporal registration and data fusion of visual perception data from fisheye cameras and distance detection data from ultrasonic radars, and comprehensively analyze the location and distance information of obstacles to enhance the reliability and fault tolerance of near-distance obstacle detection in parking scenarios.

[0144] The parking planning module is used to perform parking space search and recognition, automatic parking path generation, obstacle avoidance trajectory planning, and motion control command output based on the fused surround view environmental perception information, so as to realize the decision-making and execution of automatic parking function.

[0145] The SOC (System-Oriented Control) state machine is used to uniformly manage the state lifecycle of driving and parking modes, realize the safe mutual exclusion, time-sharing multiplexing and state transition control of functional modules in the two modes, and automatically switch the function activation state according to the vehicle dynamics state and scene semantics.

[0146] Other process modules of the SOC are used to carry out basic system-level support tasks, including but not limited to peripheral driver management, inter-process communication (IPC), system resource scheduling, fault diagnosis and monitoring, log recording and data storage management, to ensure the stable operation of the overall SOC system.

[0147] After introducing the SOC, the MCU will now be explained: The MCU is a chip in the intelligent driving domain controller, used to receive parking switching commands issued by the SOC and complete corresponding operations. It is also used to access millimeter-wave and ultrasonic data. The MCU includes: a forward-looking millimeter-wave fusion module, a millimeter-wave data processing module, a driving planning module, a driving control module, a parking control module, an ultrasonic data processing module, an MCU parking state machine, and other MCU process modules. The forward-looking millimeter-wave fusion module is used to receive the detection data from the forward-looking millimeter-wave radar and perform spatiotemporal registration and fusion processing with the visual data output by the SOC forward-looking perception module. In driving mode, it enables long-distance, high-precision perception of obstacles and traffic participants, improving the reliability and anti-interference capability of environmental detection.

[0148] The millimeter-wave data processing module is used to analyze, filter and denoise, cluster targets and predict trajectories of point cloud data, distance information, speed information and angle information output by millimeter-wave radar, providing stable physical environment perception data support for the driving planning module.

[0149] The driving planning module is used to generate real-time feasible driving paths in driving mode based on forward perception, millimeter wave fusion and vehicle dynamics data, to perform acceleration and deceleration planning, lane change planning and obstacle avoidance decisions, and output motion control commands.

[0150] The driving control module receives motion control commands from the driving planning module and performs low-level control of the vehicle's power system, steering system, and braking system in driving mode, including acceleration, deceleration, steering, and following / cruise control, to ensure the precise execution of the vehicle's motion status.

[0151] The parking control module receives path instructions from the SOC parking planning module and performs precise control of vehicle steering, throttle, and braking in parking mode, enabling the execution and dynamic adjustment of functions such as automatic parking, remote parking, and memory parking.

[0152] The ultrasonic data processing module is used to receive near-range detection data from the ultrasonic radar, perform data validity verification, filtering, and obstacle distance / direction analysis, and compensate for visual perception blind spots in parking mode to improve obstacle avoidance safety redundancy at low distances.

[0153] The MCU parking state machine serves as the underlying execution state hub of the intelligent driving domain controller. It receives and parses the parking switching instructions issued by the SOC parking state machine, manages the state activation and mutual exclusion control of the various functional modules of the MCU itself, and coordinates the orderly switching of driving and parking functions.

[0154] Other process modules of the MCU are used to carry out system-level support tasks within the MCU other than the core control logic of the navigation bar, including but not limited to peripheral driver management, data communication protocol processing, fault diagnosis and safety monitoring, power management and logging, to ensure the stable, reliable and safe operation of the entire MCU system.

[0155] Based on the same inventive concept, after introducing a berthing control method provided by the embodiments of this application, as follows: Figure 10 As shown, the following describes a berthing control device 1000 with a first controller as the execution subject provided in an embodiment of this application. The device includes: The response module 10001 is used to respond to the vehicle's power-on command and control the vehicle to start the parking mode. The receiving module 10002 is used to determine whether the vehicle is in a pre-marked target area based on the received first current map location information when it is determined that the parking function corresponding to the parking mode is inactive. The vehicle speed acquisition module 10003 is used to acquire the current vehicle speed when the vehicle is not in the target area; The mode switching module 10004 is used to control the vehicle to start a driving mode if it is determined that the current vehicle speed is greater than a first preset vehicle speed; the driving mode is the working mode that realizes the driving function.

[0156] In some possible embodiments, the receiving module 10002 is further configured to: when the vehicle is in the target area, generate a first prompt in response to a user-triggered driving activation command, the first prompt being used to inform the user that it is not recommended to enable driving functions in the current area.

[0157] In some possible embodiments, the receiving module 10002 is further configured to: when the vehicle is in the target area; if the duration of the vehicle's stay in the target area is greater than a first preset duration, generate a first prompt in response to a user-triggered driving activation command.

[0158] In some possible embodiments, the receiving module 10002 is further configured to: if a user-triggered driving activation command is detected within a second preset time period after the first prompt is generated, control the vehicle to start driving mode.

[0159] In some possible embodiments, the mode switching module 10004 is further configured to: determine whether the vehicle is in a pre-marked target area based on the received second current map location information when the driving function corresponding to the driving mode is inactive; and control the vehicle to start the parking mode when the vehicle is in the target area.

[0160] In some possible embodiments, the mode switching module 10004 is further configured to: determine available parking spaces based on the second current map location information; the available parking spaces are used for parking when the user activates the parking function.

[0161] In some possible embodiments, the mode switching module 10004 is further configured to: generate a second prompt in response to a parking activation command triggered by the user when the vehicle is not in the target area, the second prompt being used to inform the user that it is not recommended to enable the parking function in the current area.

[0162] In some possible embodiments, the mode switching module 10004 is further configured to: when the vehicle is not in the target area, obtain the current speed of the vehicle in response to a parking activation command triggered by the user; if it is determined that the current speed is less than a second preset speed, control the vehicle to start the parking mode.

[0163] In some possible embodiments, the vehicle speed acquisition module 10003 is further configured to: if it is determined that the current vehicle speed is greater than or equal to a second preset vehicle speed, generate a third prompt, the third prompt being used to inform the user to reduce the vehicle speed in order to switch modes.

[0164] In some possible embodiments, the mode switching module 10004 is further configured to: send a first parking switch command to the second controller, the first parking switch command being used to instruct the vehicle to switch from parking mode to driving mode.

[0165] In some possible embodiments, the mode switching module 10004 is further configured to: send a second driving / parking switching command to the second controller, the second driving / parking switching command being used to instruct the vehicle to switch from driving mode to parking mode.

[0166] like Figure 11 As shown, the following describes a berthing control device 1100 provided in this application embodiment, wherein the execution subject is a second controller. The device includes: The instruction receiving module 11001 is used to receive the dock switching instruction sent by the first controller; The state determination module 11002 is used to determine the first state of the vehicle based on the driving and parking switching command; if the driving and parking switching command is the first driving and parking switching command, the first state is the driving state; if the driving and parking switching command is the second driving and parking switching command, the first state is the parking state. The control module 11003 is used to stop executing instructions related to the second state and stop reporting faults related to the second state; if the parking switch instruction is the first parking switch instruction, the second state is the parking state; if the parking switch instruction is the second parking switch instruction, the second state is the driving state.

[0167] Corresponding to the above embodiments, this application also provides an electronic device. Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 1200 may include a processor 1201, a memory 1202, and a communication unit 1203. These components communicate through one or more buses. Those skilled in the art will understand that the structure of the electronic device shown in the figure does not constitute a limitation on the embodiment of this application. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0168] The communication unit 1203 is used to establish a communication channel, enabling the electronic device to communicate with other devices. It can receive user data from other devices or send user data to other devices.

[0169] The processor 1201 serves as the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 1202, and calls data stored in the memory to perform various functions and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 1201 may consist only of a central processing unit (CPU). In this embodiment, the CPU may have a single processing core or include multiple processing cores.

[0170] The memory 1202 is used to store the execution instructions of the processor 1201. The memory 1202 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0171] When the execution instructions in memory 1202 are executed by processor 1201, the electronic device 1200 is able to perform operations. Figure 2 Some or all of the steps in the illustrated embodiments.

[0172] In a specific implementation, this application also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps of the various embodiments of the navigation control method provided in this application. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0173] Those skilled in the art will clearly understand that the techniques in the embodiments of this application can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application or some parts of the embodiments.

[0174] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments and terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

Claims

1. A berthing control method, characterized in that, Applied to a first controller, the method includes: In response to the vehicle's power-on command, control the vehicle to start parking mode; When it is determined that the parking function corresponding to the parking mode is inactive, it is determined whether the vehicle is in a pre-marked target area based on the received first current map location information. When the vehicle is not in the target area, obtain the vehicle's current speed; If it is determined that the current vehicle speed is greater than the first preset vehicle speed, the vehicle is controlled to start the driving mode.

2. The method according to claim 1, characterized in that, The method further includes: When the vehicle is in the target area, a first prompt is generated in response to a user-triggered driving activation command. The first prompt is used to indicate to the user that it is not recommended to enable driving functions in the current area.

3. The method according to claim 2, characterized in that, When the vehicle is in the target area, generating a first prompt in response to a user-triggered driving activation command includes: If the vehicle is in the target area and the duration of the vehicle's stay in the target area exceeds a first preset duration, a first prompt is generated in response to a user-triggered driving activation command.

4. The method according to claim 2, characterized in that, After generating the first prompt in response to a user-triggered vehicle activation command, the method further includes: If a user-triggered driving activation command is detected within a second preset time period after the first prompt is generated, the vehicle is controlled to start driving mode.

5. The method according to any one of claims 1-4, characterized in that, After controlling the vehicle to start driving mode, the method further includes: When it is determined that the driving function corresponding to the driving mode is inactive, the vehicle is determined to be in a pre-marked target area based on the received second current map location information. When the vehicle is in the target area, control the vehicle to activate the parking mode.

6. The method according to claim 5, characterized in that, After controlling the vehicle to activate the parking mode, the method further includes: Available parking spaces are determined based on the second current map location information; the available parking spaces are used for parking when the user activates the parking function.

7. The method according to claim 5, characterized in that, The method further includes: When the vehicle is not in the target area, the current speed of the vehicle is obtained in response to a parking activation command triggered by the user; If it is determined that the current vehicle speed is less than the second preset vehicle speed, then the vehicle is controlled to start the parking mode.

8. The method according to claim 7, characterized in that, The method further includes: If it is determined that the current vehicle speed is greater than or equal to the second preset vehicle speed, a third prompt is generated, which is used to inform the user to reduce the vehicle speed in order to switch modes.

9. An electronic device, characterized in that, It includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to perform the method of any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1-8.

Images