A driving simulation control method, device and storage medium

Abstract

The application discloses a driving simulation control method and device and a storage medium, relates to the technical field of driving simulation, and comprises the following steps: receiving a driving operation instruction and an intelligent driving control instruction; in response to a mode switching instruction, determining a first mode before switching and a second mode after switching, the first mode and the second mode being different modes in an artificial control mode, a man-machine shared control mode and a machine control mode; in a preset switching duration, transitioning from the first mode to the second mode, performing weighted fusion processing on the driving operation instruction and the intelligent driving control instruction according to a first control right proportion and a second control right proportion, and driving a simulation vehicle based on a final control instruction obtained through fusion; and after the preset switching duration ends, driving the simulation vehicle in the second mode. The application introduces the preset switching duration and the weighted fusion processing, so that the control right is smoothly transitioned, and abnormal fluctuations of the vehicle state caused by instantaneous mode switching are avoided.

Description

Technical Field

[0001] This invention relates to the field of driving simulation technology, and in particular to a control method, device and storage medium for driving simulation. Background Technology

[0002] With the rapid development of intelligent driving technology, human-machine collaborative driving has become a key research direction for achieving safe and efficient travel. In the field of intelligent driving simulation testing, there are currently three main technical approaches: pure algorithm simulation platforms, virtual reality driving simulation platforms, and real vehicle driving experiments.

[0003] Pure algorithm-based intelligent driving simulation platforms, such as CARLA and Prescan, provide a fully digital closed-loop operating environment through modules such as vehicle dynamics and sensor simulation. These platforms require no driver intervention and cannot simulate real-world behavioral characteristics such as driver takeover reaction time, operating habits, and attention fluctuations, thus they cannot support simulation tests involving driver participation.

[0004] Real-vehicle driving tests are conducted by modifying mass-produced vehicles and adding intelligent driving systems and data acquisition equipment. Although this can introduce real drivers, it has drawbacks such as high experimental costs, high safety risks, difficulty in accurately reproducing scenarios, and inability to safely test extreme scenarios.

[0005] Virtual reality driving simulation platforms, such as DReyeVR, provide an immersive driving environment for drivers through virtual reality head-mounted displays and driving peripherals, enabling the introduction of real drivers into simulation testing. However, existing virtual reality driving simulation platforms have shortcomings in control mode switching: when switching between different control modes is required, the switching process lacks a transition mechanism, and the change in control mode is completed instantaneously. During driving simulation, sudden changes in control signals can easily lead to abnormal fluctuations in vehicle status, affecting the continuity and stability of simulation testing.

[0006] Therefore, how to achieve a smooth transition between different control modes in driving simulation in order to improve the continuity and stability of simulation testing is a technical problem that urgently needs to be solved.

[0007] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0008] The main objective of this application is to provide a control method, device, and storage medium for driving simulation, aiming to solve the technical problem of how to achieve a smooth transition between different control modes in driving simulation, so as to improve the continuity and stability of simulation testing.

[0009] To achieve the above objectives, this application proposes a control method for driving simulation, the method comprising: The system receives driving operation instructions and intelligent driving control instructions. The driving operation instructions are determined based on driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control instructions are generated by the intelligent driving algorithm based on the vehicle status data of the simulated vehicle and the driving operation data. In response to the received mode switching command, the first mode before switching and the second mode after switching are determined, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode; Within a preset switching time, the system transitions from the first mode to the second mode. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation command and the intelligent driving control command are weighted and fused. The simulated vehicle is then driven based on the final control command obtained from the fusion process. After the preset switching time expires, the simulated vehicle is driven in the second mode.

[0010] In one embodiment, the step of determining the first mode before the switch and the second mode after the switch includes: Obtain the current control mode of the simulated vehicle, use the current control mode as the first mode, and use the control weight ratio corresponding to the current control mode as the first control weight ratio; The control mode indicated by the mode switching command shall be used as the second mode; When the second mode is the manual control mode, the second control ratio is determined to be the preset manual control ratio value; In the case of the second mode being the human-machine shared control mode, the second control ratio is determined to be the target ratio value corresponding to the shared ratio parameter based on the sharing ratio parameter carried in the mode switching instruction. When the second mode is the machine control mode, the second control ratio is determined to be a preset machine control ratio value.

[0011] In one embodiment, the step of transitioning from the first mode to the second mode within a preset switching time, and performing weighted fusion processing on the driving operation commands and the intelligent driving control commands according to the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, includes: At each sampling time within the preset switching duration, the intermediate control ratio corresponding to each sampling time is determined based on the preset control allocation strategy, the first control ratio, and the second control ratio. Based on the intermediate control weight ratio corresponding to each sampling time, the driving operation command and the intelligent driving control command corresponding to each sampling time are weighted and fused to obtain the final control command corresponding to each sampling time.

[0012] In one embodiment, after the step of driving the simulated vehicle in the second mode, the method further includes: Based on the state data and driving operation data of the simulated vehicle within the preset switching time, a driving quality evaluation index is calculated. Based on the driving quality evaluation index, the performance of the combination of the intelligent driving algorithm and the control allocation strategy is evaluated, and an algorithm performance evaluation report is generated. The driving quality assessment indicators include at least one of the following: steering conflict degree, longitudinal pulse rate, vehicle yaw ratio, pedal sudden change energy, speed matching error, cumulative takeover stress, input conflict error, safe braking time index, and trajectory lane error.

[0013] In one embodiment, prior to the step of responding to a received mode switching instruction, the method further includes: In response to the driver pressing a programmable button on the driving peripheral, the mode switching command is generated; and / or, The system receives a control adjustment request sent by the intelligent driving algorithm through a standardized algorithm interface, and generates the mode switching instruction based on the control adjustment request.

[0014] In one embodiment, prior to the step of receiving driving operation commands and intelligent driving control commands, the method further includes: Read a predefined scene configuration file to parse and obtain scene configuration parameters, wherein the scene configuration parameters include at least one of scene type, vehicle speed, trigger distance and weather conditions; Generate the corresponding simulation scenario based on the scenario configuration parameters; Initialize the states of the simulated vehicles and traffic participants in the simulation scenario; The scenario types include at least one of the following: sudden braking by the vehicle in front, pedestrian crossing, lane departure, detour through construction zone, and vehicle cutting in.

[0015] In one embodiment, the step of receiving driving operation commands and intelligent driving control commands includes: The driving operation data is collected through the driving peripheral device, wherein the driving peripheral device includes a steering wheel, an accelerator pedal and a brake pedal, and the driving operation data includes at least one of steering angle, accelerator pedal pressure and brake pedal pressure. The vehicle status data and driving operation data are sent to the intelligent driving algorithm through a standardized algorithm interface; Receive the intelligent driving control command returned by the intelligent driving algorithm through the standardized algorithm interface; The standardized algorithm interface provides functions for obtaining vehicle status, obtaining driver status, setting control allocation ratio, and sending vehicle control commands.

[0016] In one embodiment, after the step of sending the vehicle status data and the driving operation data to the intelligent driving algorithm through a standardized algorithm interface, the method further includes: The driver's eye movement data is collected through a virtual reality display device, and the eye movement data includes at least one of the following: fixation point coordinates, pupil diameter, and eyelid closure degree; The eye-tracking data is sent to the intelligent driving algorithm through the standardized algorithm interface.

[0017] Furthermore, to achieve the above objectives, this application also proposes a control device for driving simulation, the control device for driving simulation comprising: The instruction acquisition module is used to receive driving operation instructions and intelligent driving control instructions. The driving operation instructions are determined based on driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control instructions are generated by the intelligent driving algorithm based on the vehicle status data of the simulated vehicle and the driving operation data. The mode confirmation module is used to respond to the received mode switching command and determine the first mode before switching and the second mode after switching, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode; The switching control module is used to transition from the first mode to the second mode within a preset switching time. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation command and the intelligent driving control command are weighted and fused. The simulated vehicle is driven based on the final control command obtained by the fusion process. The mode driving module is used to drive the simulated vehicle in the second mode after the preset switching time has ended.

[0018] In addition, to achieve the above objectives, this application also proposes a control device for driving simulation, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the control method for driving simulation as described above.

[0019] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the driving simulation control method as described above.

[0020] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the driving simulation control method described above.

[0021] This application provides a control method for driving simulation. First, it receives driving operation instructions and intelligent driving control instructions. In response to the received mode switching instructions, it determines a first mode before switching and a second mode after switching. Within a preset switching time, it transitions from the first mode to the second mode. Based on the first control weight ratio corresponding to the first mode and the second control weight ratio corresponding to the second mode, it performs weighted fusion processing on the driving operation instructions and intelligent driving control instructions. Based on the final control instructions obtained from the fusion processing, it drives the simulated vehicle. After the preset switching time ends, it drives the simulated vehicle in the second mode.

[0022] The above method introduces a preset switching duration as a transition interval during mode switching. Within this interval, driving operation commands and intelligent driving control commands are weighted and fused based on the first and second control weight ratios. The weighting coefficients of this fusion gradually change within the transition interval, ensuring a smooth transition from the control state corresponding to the first mode to the control state corresponding to the second mode. This avoids abnormal fluctuations in vehicle status caused by instantaneous mode switching. Furthermore, the preset switching duration makes the transition process configurable, providing a flexible and controllable transition scheme for control mode switching in different scenarios. This addresses the lack of a transition mechanism in existing driving simulation platforms during control mode switching. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating an embodiment of the driving simulation control method of this application. Figure 2This is a block diagram of the overall architecture of the driving simulation control platform provided in the embodiments of this application; Figure 3 A flowchart illustrating the control method for driving simulation provided in an embodiment of this application; Figure 4 This is a schematic diagram of the module structure of the control device for driving simulation according to an embodiment of this application; Figure 5 This is a schematic diagram of the equipment structure of the hardware operating environment involved in the driving simulation control method in the embodiments of this application.

[0026] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0027] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0028] This application provides a control method for driving simulation, applicable to simulation testing scenarios of human-machine cooperative driving. In existing driving simulation platforms, when switching between different control modes, the switching process lacks a transition mechanism. The change in control mode is instantaneous, leading to abrupt changes in control signals and causing abnormal fluctuations in the simulated vehicle's state, affecting the continuity and stability of the simulation test. Furthermore, addressing the lack of a unified standardized framework for scenario configuration, control mode switching mechanisms, and algorithm interfaces in existing simulation platforms, and the incomparability of results from different test schemes, this application also provides a standardized scenario configuration method, a unified standardized algorithm interface, and a driving quality evaluation index system. This enables the configuration, switching, and horizontal comparison of different combinations of intelligent driving algorithms and control allocation strategies under the same simulation conditions, thereby comprehensively verifying the overall performance of different algorithms and switching schemes.

[0029] To facilitate understanding of the technical solution of this application, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments.

[0030] It should be noted that the executing entity in the embodiments of this application can be a computing service device with data processing, network communication, and program execution functions, such as a personal computer, workstation, or server. The following description uses a computing device as an example to illustrate each embodiment.

[0031] Example 1 This embodiment provides a control method for driving simulation. (Refer to...) Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the driving simulation control method of this application. The method includes the following steps: Step S10: Receive driving operation instructions and intelligent driving control instructions. The driving operation instructions are determined based on driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control instructions are generated by the intelligent driving algorithm based on the vehicle status data and driving operation data of the simulated vehicle.

[0032] It should be noted that driving simulation refers to constructing a virtual driving environment through a computer simulation engine, where the driver interacts with the virtual driving environment via driving peripherals. The simulated vehicle refers to a virtual vehicle controlled jointly or separately by the driver and intelligent driving algorithms within the simulation engine. For example, the simulation engine could be CARLA (Car Learning to Act, an open-source intelligent driving simulation engine). CARLA is built on Unreal Engine and provides high-fidelity simulation maps of urban roads, highways, and rural roads, supporting functions such as vehicle dynamics simulation, sensor simulation, and traffic flow generation.

[0033] Driving peripherals refer to physical devices used by drivers to input driving operations, including but not limited to steering wheels, accelerator pedals, and brake pedals. For example, a driving peripheral could be the Logitech G29 force feedback steering wheel kit, which includes a force feedback steering wheel and non-linear accelerator / brake pedals. The force feedback steering wheel can simulate steering resistance, self-centering torque, and collision impacts on different road surfaces, providing the driver with a near-realistic driving feel. The non-linear accelerator and brake pedals can replicate the pedal damping characteristics and pedal travel of a real vehicle, making the driver's acceleration and braking operations more precise. The driving peripheral connects to a computing device via a USB interface, and the computing device collects driving operation data through the driving peripheral's driver interface or SDK.

[0034] Driving operation data refers to raw data collected through driving peripherals that reflects the driver's operating intentions. Driving operation data includes at least one of steering angle, accelerator pedal pressure, and brake pedal pressure. For example, for the Logitech G29 steering wheel, the steering angle can be read from the steering wheel's rotary encoder, typically ranging from -450 degrees to +450 degrees (corresponding to one and a half turns to the left and right); the accelerator and brake pedal pressure can be read from the pedal potentiometers, with values ​​normalized to between 0 and 1.

[0035] Vehicle status data refers to the physical state information of the simulated vehicle at the current moment, including at least one of position, velocity, acceleration, and yaw rate. Position indicates the simulated vehicle's coordinates on the simulation map, velocity indicates the vehicle's speed, acceleration indicates the rate of change of velocity, and yaw rate indicates the vehicle's rotational angular velocity about its vertical axis. Vehicle status data can be collected through the application programming interface (API) provided by the simulation engine. For example, in CARLA, position can be obtained by calling `vehicle.get_location()`, velocity by `vehicle.get_velocity()`, acceleration by `vehicle.get_acceleration()`, and yaw rate by `vehicle.get_angular_velocity()`.

[0036] Intelligent driving algorithms refer to algorithmic programs that can generate control commands based on vehicle status data and driving operation data. Intelligent driving algorithms can be rule-based traditional control algorithms, end-to-end algorithms based on deep learning, or decision-making algorithms based on reinforcement learning. For example, intelligent driving algorithms can run locally on a computing device or on a remote server via a network, interacting with the computing device through standardized algorithm interfaces.

[0037] Driving operation commands are determined based on driving operation data. For example, the computing device converts the collected steering angle into a steering command for the simulated vehicle according to the steering ratio coefficient of the simulation engine, and converts the accelerator pedal force and brake pedal force into accelerator and brake commands for the simulated vehicle, respectively. Intelligent driving control commands are generated by intelligent driving algorithms based on vehicle status data and driving operation data, and include steering commands, accelerator commands, and brake commands.

[0038] During the simulation, the computing device executes this step cyclically at a fixed frame rate, continuously receiving driving operation commands and intelligent driving control commands. For example, the fixed frame rate can be 30Hz, meaning it executes the loop once every 0.033 seconds.

[0039] Step S20: In response to the received mode switching instruction, determine the first mode before switching and the second mode after switching, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode.

[0040] It should be noted that the mode switching command refers to the command used to trigger the switching of the control mode of the simulated vehicle. The control mode refers to the source mode of the control command received by the simulated vehicle, including manual control mode, human-machine shared control mode, and machine control mode.

[0041] Manual control mode refers to a control mode where the accelerator, brakes, and steering of the simulated vehicle are all operated by the driver through driving peripherals. In manual control mode, the intelligent driving algorithm can output control commands to the computing device, but these commands are not used to drive the simulated vehicle; they serve only as reference commands. For example, in manual control mode, the driver needs to complete a full driving operation, while the intelligent driving algorithm runs in parallel in the background, outputting reference commands. Comparing the reference commands with the driver's actual operating commands can be used to assess the anthropomorphism of the intelligent driving algorithm—that is, how closely the algorithm's output commands resemble the actions of a human driver.

[0042] Machine control mode refers to a control mode in which the accelerator, brakes, and steering of the simulated vehicle are all controlled by intelligent driving algorithms. In machine control mode, the driver does not perform driving operations but acts only as an observer. For example, machine control mode is used to test the independent driving ability of intelligent driving algorithms under conditions without human intervention.

[0043] Human-machine shared control mode refers to a control mode in which the simulated vehicle is jointly controlled by a driver and an intelligent driving algorithm. In this mode, driver operation commands and intelligent driving control commands are merged according to a certain ratio to obtain the final control commands. The control weight ratio is used to measure the weight of the intelligent driving control commands in the fusion result. For example, when the control weight ratio is 30%, it means that the intelligent driving control commands account for 30% of the weight in the final control commands, and the driver operation commands account for 70%; when the control weight ratio is 70%, it means that the intelligent driving control commands account for 70% of the weight, and the driver operation commands account for 30%. The control weight ratio can be continuously adjusted within a range greater than zero and less than 100%.

[0044] The first mode refers to the control mode before the switch, and the second mode refers to the control mode after the switch. The first and second modes are different modes among manual control mode, human-machine shared control mode, and machine control mode. That is, mode switching means that the control mode has changed. For example, if the first mode is manual control mode and the second mode is machine control mode, it means that this mode switch is from manual control mode to machine control mode; if the first mode is machine control mode and the second mode is human-machine shared control mode, it means that it is from machine control mode to human-machine shared control mode.

[0045] Upon receiving the mode switching command, the computing device obtains the control mode of the simulated vehicle at the current moment, which is designated as the first mode; it then parses the target control mode from the mode switching command, which is designated as the second mode. The method for generating the mode switching command will be described in subsequent embodiments.

[0046] Step S30: Within a preset switching time, transition from the first mode to the second mode. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, perform weighted fusion processing on the driving operation command and the intelligent driving control command, and drive the simulated vehicle based on the final control command obtained from the fusion processing.

[0047] It should be noted that the preset switching duration refers to the pre-configured length of time used for the transition process of the control mode. The preset switching duration can be configured via parameters before the simulation experiment begins. For example, the preset switching duration can be configured within the range of 0.1 seconds to 2.0 seconds, with a default value of 0.5 seconds. Too short a transition time may cause abrupt changes in vehicle state, while too long a transition time may cause the driver to experience a response delay. Users can flexibly select an appropriate transition duration according to the specific simulation scenario and testing requirements. For example, in high-speed driving scenarios, a shorter transition duration (such as 0.3 seconds) can be selected to reduce vehicle instability during the transition, while in low-speed urban scenarios, a longer transition duration (such as 1.0 second) can be selected to provide a smoother driving experience.

[0048] The first control ratio refers to the control ratio corresponding to the first mode. The second control ratio refers to the control ratio corresponding to the second mode. The method for determining the control ratio will be explained in subsequent embodiments.

[0049] Weighted fusion processing refers to the process of weighting and summing the driving operation commands and intelligent driving control commands at each sampling time within a preset switching time to obtain the final control command. At each sampling time within the preset switching time, the computing device obtains the driving operation commands and intelligent driving control commands at the current time and performs weighted fusion according to the control weight ratio corresponding to the current time.

[0050] The weighted fusion process can be expressed by the following formula:

[0051] in, Indicates the final control command. Indicates driving operation commands. This represents the intelligent driving control command, where w represents the weighting coefficient, which is the control weight ratio at the current sampling time. Within a preset switching time, w gradually changes from the first control weight ratio to the second control weight ratio. The final control command is used to drive the simulated vehicle in the simulation engine, including steering control, throttle control, and braking control.

[0052] For example, assume the first mode is manual control (first control ratio is 0%), and the second mode is machine control (second control ratio is 100%), with a preset switching time of 0.5 seconds. At the start of the transition (t=0), w=0, and the final control command is completely equal to the driving operation command, meaning it is entirely controlled by the driver. In the middle of the transition (t=0.25 seconds), w=50%, and the final control command is composed of equal weights from the driving operation command and the intelligent driving control command. At the end of the transition (t=0.5 seconds), w=100%, and the final control command is completely equal to the intelligent driving control command, meaning it is entirely controlled by the intelligent driving algorithm. Throughout the transition, control is smoothly transferred from the driver to the intelligent driving algorithm. The driver can feel the gradual weakening of the steering wheel force feedback and the gradual takeover by the intelligent driving algorithm, without any sudden jumps in control.

[0053] In another example, the first mode is machine control mode (first control ratio is 100%), and the second mode is human-machine shared control mode, with the second control ratio being 30%. At the start of the transition, w=100%, and the final control command is completely equal to the intelligent driving control command; at the end of the transition, w=30%, and the final control command has an intelligent driving control command weight of 30% and a driving operation command weight of 70%. The transition process achieves a smooth transition from complete machine control to human-machine shared control.

[0054] Step S40: After the preset switching time has ended, drive the simulated vehicle in the second mode.

[0055] It should be noted that after the preset switching time expires, the transition process is complete, and the simulated vehicle enters the steady-state control state corresponding to the second mode. If the second mode is a manual control mode, the simulated vehicle is driven solely by driving operation commands. If the second mode is a machine control mode, the simulated vehicle is driven solely by intelligent driving control commands. If the second mode is a human-machine shared control mode, the simulated vehicle is driven after weighted fusion of driving operation commands and intelligent driving control commands according to the second control weight ratio. The difference from step S30 is that the control weight ratio remains constant and no longer changes in this case.

[0056] In this embodiment, through steps S10 to S40, a preset switching duration is introduced as a transition interval during the mode switching process. Within the transition interval, driving operation commands and intelligent driving control commands are weighted and fused based on the first control weight ratio and the second control weight ratio. The weighting coefficient of the weighted fusion gradually changes within the preset switching duration, so that the final control command smoothly transitions from the control state corresponding to the first mode to the control state corresponding to the second mode, avoiding abnormal fluctuations in vehicle state caused by instantaneous switching of control modes. At the same time, the preset switching duration makes the time range of the transition process configurable, providing a flexible and controllable transition scheme for control mode switching in different scenarios. The introduction of three control modes—manual control mode, human-machine shared control mode, and machine control mode—allows the human-machine shared control mode to be used alongside the manual control mode and machine control mode as the starting point or end point of control power switching, providing a complete mode framework for human-machine collaborative control research.

[0057] Example 2 This embodiment further refines steps S20 and S30 based on embodiment one, and explains the driving quality assessment process after the transition is completed.

[0058] In one feasible implementation, determining the first mode before switching and the second mode after switching in step S20 can be further achieved through the following steps: Step S210: Obtain the current control mode of the simulated vehicle, take the current control mode as the first mode, and take the control weight ratio corresponding to the current control mode as the first control weight ratio.

[0059] It should be noted that the simulated vehicle remains in a specific control mode throughout the simulation. The computing device retrieves the current control mode and its corresponding control weight ratio by querying the simulated vehicle's status record. Each control mode corresponds to a control weight ratio, which can be a preset value or a value determined based on the preceding transition process. For example, if the current control mode is manual, the current control weight ratio is zero; if the current control mode is machine-controlled, the current control weight ratio is 100%; if the current control mode is a human-machine shared control mode, the current control weight ratio is the ratio value at the end of the previous transition, which is greater than zero and less than 100%.

[0060] Step S220: The control mode indicated by the mode switching command is used as the second mode.

[0061] Step S230: When the second mode is manual control mode, the second control ratio is determined to the preset manual control ratio value.

[0062] It should be noted that the preset manual control ratio refers to the weight of machine control commands in the weighted fusion process under manual control mode; this value is a pre-configured value. In manual control mode, the simulated vehicle is driven solely by driving operation commands; machine control commands do not participate in driving. Therefore, the preset manual control ratio is configured to zero. It can be understood that expressing the control weight ratio under manual control mode as a preset parameter ensures that the control weight ratios under manual control mode, machine control mode, and human-machine shared control mode are all within a unified parameterized framework, facilitating the recording, comparison, and connection of control weight ratios during mode switching. For example, when the simulated vehicle switches from human-machine shared control mode to manual control mode, the control weight ratio is adjusted from the initial value at the start of the transition to zero.

[0063] Step S240: In the case of the second mode being the human-machine shared control mode, the second control ratio is determined to be the target ratio value corresponding to the shared ratio parameter based on the shared ratio parameter carried in the mode switching instruction.

[0064] It should be noted that the sharing ratio parameter is used to specify the weight of intelligent driving control commands in the human-machine shared control mode. For example, if the sharing ratio parameter is 30%, the second control weight ratio is 30%; if the sharing ratio parameter is 60%, the second control weight ratio is 60%. The value of the sharing ratio parameter is greater than zero and less than 100%, allowing the driver and the intelligent driving algorithm to participate in the control of the simulated vehicle in any proportion. For example, in a high-speed cruise scenario, a higher sharing ratio parameter (e.g., 80%) can be set, with the intelligent driving algorithm leading the driving and the driver primarily monitoring; in complex urban road conditions, a lower sharing ratio parameter (e.g., 30%) can be set, with the driver leading the driving and the intelligent driving algorithm providing assistance.

[0065] Step S250: When the second mode is machine control mode, the second control ratio is determined to a preset machine control ratio value.

[0066] It should be noted that the preset machine control ratio refers to the weight of machine control commands in the weighted fusion process under machine control mode; this value is a pre-configured value. In machine control mode, the simulated vehicle is driven solely by machine control commands; driving operation commands do not participate in driving. Therefore, the preset machine control ratio is configured to 100%. The control weight ratio in machine control mode is also expressed as a preset parameter, consistent with the processing method in manual control mode. For example, when the simulated vehicle switches from human-machine shared control mode to machine control mode, the control weight ratio is adjusted from the initial value at the start of the transition to 100%.

[0067] In one feasible implementation, in step S30, within a preset switching time, the transition from the first mode to the second mode is performed. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation commands and intelligent driving control commands are weighted and fused. This can be further achieved through the following steps: Step S310: At each sampling time within the preset switching duration, based on the preset control allocation strategy, the first control ratio, and the second control ratio, determine the intermediate control ratio corresponding to each sampling time.

[0068] It should be noted that the control allocation strategy refers to the method by which the control ratio changes from the first control ratio to the second control ratio within a preset switching time. Different control allocation strategies define different change curves, thus producing different transition effects and driving experiences.

[0069] A sampling moment refers to a discrete time point within a preset switching duration, divided by a fixed sampling period. For example, the sampling period is consistent with the simulation frame rate, such as sampling once every 0.033 seconds (corresponding to a 30Hz frame rate). With a preset switching duration of 0.5 seconds, there are approximately 15 sampling moments.

[0070] For example, the control allocation strategy can be a linear interpolation strategy. At each sampling moment within a preset switching duration, the intermediate control weight ratio is calculated using linear interpolation. Let the first control weight ratio be w1, the second control weight ratio be w2, the preset switching duration be T, and the transition time used at the current sampling moment be t (calculated from the start of the transition). Then, the intermediate control weight ratio w can be calculated using the following formula:

[0071] Here, t ranges from 0 to T, and w gradually changes from w1 to w2. When t=0, w=w1; when t=T, w=w2. The linear interpolation strategy is characterized by a uniform change in the control weight ratio over time, resulting in a smooth and predictable transition process.

[0072] In another example, the control allocation strategy can also be a non-linear strategy, such as the S-curve strategy. In the initial stage of the transition, w changes slowly from w1, giving the driver sufficient time to perceive and adapt to the change in control. In the middle stage of the transition, the rate of change of w accelerates, achieving a rapid transfer of control. In the final stage of the transition, the rate of change of w slows down again, smoothly reaching w2. The S-curve strategy can be achieved using the following formula:

[0073] Where f is a sigmoid mapping function, such as a cosine function: Alternatively, other smooth functions such as logical functions can be used.

[0074] In another example, the control allocation strategy can also be an adaptive strategy—the proportion of intermediate control depends not only on the time progress but also on the complexity of the current driving scenario or the driver's real-time state. For example, when the intelligent driving algorithm detects a sudden increase in scenario complexity, it can proactively slow down the speed of control transfer, waiting for the driver to be fully prepared before continuing the transition.

[0075] Step S320: Based on the intermediate control weight ratio corresponding to each sampling time, the driving operation command and the intelligent driving control command corresponding to each sampling time are weighted and fused to obtain the final control command corresponding to each sampling time.

[0076] In one feasible implementation, after step S40, which involves driving the simulated vehicle in the second mode, a driving quality assessment step may also be included: Step S410: Calculate driving quality evaluation indicators based on the state data and driving operation data of the simulated vehicle within the preset switching time.

[0077] It should be noted that the driving quality assessment indicators are used to quantify the driving quality during the mode switching transition process from multiple dimensions. The driving quality assessment indicators include at least one of the following: Steering Conflict Measure (SCM) is used to assess the degree of control conflict between the driver and the intelligent driving algorithm during steering. A high steering conflict metric indicates a lack of coordination in human-machine collaborative control when the driver and the intelligent driving algorithm output steering commands in opposite directions at the same time. The steering conflict metric can be obtained by calculating the difference between the steering component in the driving operation command and the steering component in the intelligent driving control command.

[0078] Longitudinal Pulse Rate (LPR) is used to evaluate the smoothness of longitudinal control (accelerator and brake). A high LPR indicates insufficient smoothness in longitudinal control when accelerator or brake commands change frequently and significantly within a short period, potentially affecting ride comfort. The LPR can be obtained by calculating the rate of change of accelerator and brake commands between adjacent sampling times.

[0079] Speed ​​Matching Error (SME) is used to evaluate the deviation between the actual vehicle speed and the desired vehicle speed. The desired vehicle speed can be the target speed output by the intelligent driving algorithm or the target speed defined in the scenario configuration file. The speed matching error can be obtained by integrating the absolute value of the difference between the actual speed and the desired speed over the transition time.

[0080] Cumulative Takeover Stress (CTS) is used to assess the cumulative stress level of a driver during takeover. CTS can be calculated based on the driver's physiological data during the transition (such as changes in pupil diameter and heart rate variability). Changes in pupil diameter reflect the driver's cognitive load—a greater increase in pupil diameter indicates a higher cognitive load. CTS can be obtained by integrating the change in pupil diameter relative to baseline over the transition duration.

[0081] Input Conflict Error (ICE) is used to evaluate the difference between driving operation commands and intelligent driving control commands. ICE is calculated by taking a weighted average of the differences between the driving operation commands and intelligent driving control commands at each sampling time.

[0082] The Safety Braking Time Index (SBTI) assesses the time margin required for safe braking under current conditions. A lower SBTI indicates a tighter safety margin. The SBTI is calculated by dividing the current vehicle speed by the maximum braking deceleration and comparing this division with the current following distance.

[0083] Trajectory Lane Error (TLE) is used to assess the deviation between the vehicle's actual trajectory and the lane centerline. A large TLE indicates that the vehicle has deviated from its lane, which may be related to instability in steering control. TLE can be calculated by determining the lateral distance between the vehicle's position and the lane centerline.

[0084] Step S420: Based on driving quality evaluation indicators, perform performance evaluation on the combination of intelligent driving algorithm and control allocation strategy, and generate algorithm performance evaluation report. The driving quality evaluation indicators include at least one of the following: steering conflict degree, longitudinal impulse rate, vehicle yaw ratio, pedal sudden change energy, speed matching error, cumulative takeover stress, input conflict error, safe braking time index, and trajectory lane error.

[0085] It should be noted that the algorithm performance evaluation report is a comprehensive evaluation of the combination of intelligent driving algorithms and control allocation strategies. The evaluation report may include numerical values ​​for various driving quality evaluation indicators, a comprehensive score, and comparisons with benchmark values. For example, the evaluation report can be output in text or chart format to facilitate subsequent analysis by researchers.

[0086] In this embodiment, steps S210 to S250 clarify the determination method of the first and second control rights ratios, ensuring that the values ​​of the control rights ratios correspond one-to-one with each control mode. Steps S310 to S320 define the change curve of the intermediate control rights ratio using a control rights allocation strategy. Different strategies, such as linear interpolation, S-curve, and adaptive strategies, allow for flexible selection of the transition process based on different testing requirements. Steps S410 to S420 quantify the transition process using driving quality evaluation indicators from multiple dimensions, including steering conflict degree, longitudinal impulse rate, and vehicle yaw ratio. This allows for performance comparison of different combinations of intelligent driving algorithms and control rights allocation strategies under a unified indicator system. Since each experiment uses the same scenario configuration, the same standardized algorithm interface, and the same evaluation indicator system, the experimental results of different strategies are comparable, thus enabling comprehensive verification of the performance of different control rights allocation strategies and adaptive switching algorithms.

[0087] Example 3 Based on Example 1, this embodiment further explains the generation method of mode switching instructions, the configuration method of simulation scenarios, the acquisition method of driving operation instructions and intelligent driving control instructions, and the acquisition method of eye-tracking data.

[0088] In one feasible implementation, prior to step S20, which responds to the received mode switching instruction, a step of generating a mode switching instruction is further included. The step of generating the mode switching instruction includes at least one of the following methods: Method 1: In response to the driver's pressing of the programmable button on the driving peripheral, a mode switching command is generated.

[0089] It should be noted that the driving peripherals are equipped with programmable buttons. For example, the force feedback steering wheel has multiple programmable buttons, and the driver can pre-configure one of them as a mode switching button. During simulation, when the driver presses this mode switching button, the computing device generates a mode switching command. This command carries information about the target control mode. The target control mode can be a pre-configured default switching target—for example, switching in a cyclical order of "manual control → human-machine shared control → machine control → manual control" each time the mode switching button is pressed. Alternatively, the target mode can be determined based on a combination of buttons—for example, pressing once switches to human-machine shared control, and pressing twice switches to machine control.

[0090] Method 2: Receive the control adjustment request sent by the intelligent driving algorithm through the standardized algorithm interface, and generate a mode switching instruction based on the control adjustment request.

[0091] It should be noted that the standardized algorithm interface is a predefined interface specification for data interaction between computing devices and intelligent driving algorithms. Intelligent driving algorithms can proactively send control adjustment requests when they detect specific conditions. For example, specific conditions include: detecting an emergency obstacle ahead, detecting driver inattention, or detecting the vehicle about to deviate from its lane. The control adjustment request carries the target control mode and sharing ratio parameters. For instance, when the intelligent driving algorithm detects signs of driver fatigue (such as persistently high eyelid closure), it can send a control adjustment request to the computing device, requesting a switch to machine control mode, whereby the intelligent driving algorithm takes over vehicle control to ensure driving safety. Upon receiving the control adjustment request, the computing device generates a corresponding mode switching instruction.

[0092] In one feasible implementation, prior to step S10, which involves receiving driving operation commands and intelligent driving control commands, a simulation scenario configuration and generation step is also included: Step S610: Read the predefined scene configuration file to parse and obtain the scene configuration parameters, wherein the scene configuration parameters include at least one of scene type, vehicle speed, trigger distance and weather conditions.

[0093] It should be noted that the scenario configuration file is a structured text configuration file using JSON (JavaScript Object Notation) format. JSON format offers good readability and cross-platform compatibility, allowing researchers to directly modify configuration parameters using a text editor.

[0094] Scene configuration parameters include at least one of the following: scene type, vehicle speed, trigger distance, and weather conditions. For example, a typical configuration file for a scenario involving sudden braking by the vehicle in front would look like this: {"scene_type":"front_vehicle_brake","location":"Town03 / Highway","ego_speed":50,"target_speed":30,"trigger_distance":50,"weather":"ClearNoon","traffic_density":0.3} Among them, "scene_type" represents the scene type, "location" represents the simulation map and road segment, "ego_speed" represents the initial speed of the vehicle (unit: km / h), "target_speed" represents the target speed (unit: km / h), "trigger_distance" represents the distance to trigger the takeover event (unit: m), "weather" represents the weather conditions, and "traffic_density" represents the traffic density (value range 0 to 1, 0 represents no other vehicles, 1 represents full-density traffic flow).

[0095] Different scenario types correspond to different configuration parameter examples. For example, in the configuration file for a pedestrian crossing scenario, the "scene_type" value is "pedestrian_cross", and additional parameters such as the pedestrian's appearance location and crossing speed can be configured. In the configuration file for a lane departure scenario, parameters such as the departure direction and departure rate can be configured.

[0096] Step S620: Generate a corresponding simulation scenario based on the scenario configuration parameters. The scenario type includes at least one of the following: sudden braking scenario of the vehicle in front, pedestrian crossing scenario, lane departure scenario, detour scenario of construction section, and vehicle cutting in.

[0097] It should be noted that the computing device automatically loads the corresponding simulation map into the simulation engine and generates the corresponding simulation scene based on the scene configuration parameters. For example, the simulation engine builds its scene library based on Carla ScenarioRunner. Carla ScenarioRunner is a scene execution framework officially provided by CARLA, which supports defining and running standardized simulation scenes through configuration files and Python scripts.

[0098] The scenario types include at least one of the following: sudden braking by the vehicle in front, pedestrian crossing, lane departure, detour through construction zone, and vehicle cutting in. The sudden braking scenario simulates a vehicle ahead suddenly braking while traveling in front of the vehicle, used to test the driver's and intelligent driving algorithm's takeover response capabilities in emergency braking situations. The pedestrian crossing scenario simulates a pedestrian suddenly crossing the road from the side, used to test the ability to perceive and avoid vulnerable road users. The lane departure scenario simulates a vehicle gradually deviating from the center line of its current lane, used to test lane keeping assist functions and human-machine collaborative correction capabilities. The detour through construction zone scenario simulates a situation where road construction ahead requires a lane change, used to test the human-machine collaborative lane change decision-making capability. The vehicle cutting in scenario simulates a vehicle in an adjacent lane suddenly accelerating and cutting in front of the vehicle, used to test the perception and response capabilities to close-range vehicle cutting in.

[0099] Step S630: Initialize the states of the simulated vehicles and traffic participants in the simulation scenario.

[0100] It should be noted that in the generated simulation scenario, the computing device sets the initial position, initial speed, and initial direction of the simulated vehicle according to the scenario configuration parameters. Simultaneously, it initializes the states of other traffic participants, including the number, position, speed, and routes of background vehicles, as well as the positions and trajectories of pedestrians. After initialization, the computing device starts data recording and then begins the simulation run loop.

[0101] For example, in a scenario where the vehicle in front brakes suddenly, the simulation begins after initialization. The driver vehicle travels at its configured speed, while the vehicle in front travels at its configured target speed. When the distance between the driver vehicle and the vehicle in front reaches the configured trigger distance, a takeover event is triggered, generating a mode switching command, and the simulated vehicle begins the mode switching transition.

[0102] In one feasible implementation, step S10, receiving driving operation commands and intelligent driving control commands, can be further achieved through the following steps: Step S710: Collect driving operation data through driving peripherals, wherein the driving peripherals include a steering wheel, accelerator pedal and brake pedal, and the driving operation data includes at least one of steering angle, accelerator pedal force and brake pedal force.

[0103] It should be noted that driving operation data includes at least one of the following: steering angle, accelerator pedal pressure, and brake pedal pressure. The force feedback steering wheel can also output force feedback torque under the control of the simulation engine to simulate differences in steering resistance under different road conditions (such as asphalt, gravel, and icy surfaces), as well as steering wheel impact feedback during vehicle collisions.

[0104] In step S720, vehicle status data and driving operation data are sent to the intelligent driving algorithm through a standardized algorithm interface.

[0105] It should be noted that the standardized algorithm interface provides the following four core functions: The vehicle status acquisition function is used to obtain the current state data of the simulated vehicle, including position, velocity, acceleration, and yaw rate. For example, this function corresponds to calls such as `vehicle.get_location()` and `vehicle.get_velocity()` in the CARLA API.

[0106] The driver state acquisition function is used to obtain current driving operation data and eye movement data. For example, this function encapsulates calls to the driver peripheral driver interface and the virtual reality display device API, providing a unified driver state data structure to the upper-layer algorithm.

[0107] The control allocation ratio setting function is used to dynamically adjust the current control allocation ratio. For example, the input parameter of this function is a floating-point number between 0 and 1, representing the target control ratio.

[0108] The vehicle control command sending function is used to send control commands to the simulated vehicle. For example, this function corresponds to the `vehicle.apply_control()` call in the CARLA API.

[0109] Through standardized algorithm interfaces, autonomous driving algorithms do not need to understand the specific implementation details of the underlying simulation engine and hardware devices. They only need to call the four functions mentioned above to complete data acquisition, control adjustment, and command issuance. Autonomous driving algorithms from different sources (such as algorithms developed based on Carla's native Python API and algorithms developed based on C++) can all be connected to the simulation platform through standardized algorithm interfaces, significantly reducing the deployment and replacement costs of algorithms.

[0110] Step S730: Receive intelligent driving control commands returned by the intelligent driving algorithm through the standardized algorithm interface. The standardized algorithm interface provides functions for obtaining vehicle status, obtaining driver status, setting control allocation ratio, and sending vehicle control commands.

[0111] In one feasible implementation, after step S720, a step of acquiring and transmitting eye-tracking data may also be included: Step S810: Collect the driver's eye movement data through a virtual reality display device. The eye movement data includes at least one of the following: gaze point coordinates, pupil diameter, and eyelid closure degree.

[0112] It should be noted that the virtual reality display device is a head-mounted display device with eye-tracking capabilities. For example, a virtual reality display device could be the HTC VIVE Pro Eye, which incorporates Tobii eye-tracking technology with a sampling rate of 120Hz, enabling real-time acquisition of eye movement data such as gaze coordinates, pupil diameter, and eyelid closure. Other available virtual reality display devices include the Pico 4 Pro and Meta Quest Pro.

[0113] Virtual reality (VR) display devices connect to computing devices via a streaming box or USB Type-C interface. During simulation, the VR display device outputs an immersive 3D driving field of view, providing the driver with a visual experience close to real driving; simultaneously, it collects eye movement data through built-in eye-tracking sensors. The gaze point coordinates reflect the driver's gaze location in the virtual driving environment, which can be used to determine whether the driver's attention is focused on the road ahead or a specific target. Pupil diameter reflects the driver's cognitive load level—the pupil diameter increases when the driver needs to process more complex driving information. Eyelid closure reflects the driver's fatigue state—when the driver is fatigued, eyelid closure increases, manifested as a decrease in blinking frequency and an increase in the duration of eye closure.

[0114] For example, the virtual reality display device transmits the acquired eye-tracking data to the computing device via an API. In the CARLA simulation engine, integration with the virtual reality display device can be achieved through VR rendering modules (such as the DReyeVR extension).

[0115] It should be noted that if the user does not have a virtual reality display device, a regular monitor can be used to output the driving view. In this alternative, eye-tracking data acquisition is automatically disabled, but the method can still perform basic mode switching controls. If the user does not have a force feedback steering wheel, they can use a keyboard and mouse for driving operations. In this alternative, the sampling accuracy of steering and pedal data will be reduced, but the core functions of the method—mode switching and weighted fusion processing—remain unaffected.

[0116] In step S820, eye-tracking data is sent to the intelligent driving algorithm via a standardized algorithm interface.

[0117] It should be noted that the computing device, through the driver state acquisition function in the standardized algorithm interface, packages and sends the collected eye-tracking data along with driving operation data to the intelligent driving algorithm. The intelligent driving algorithm can determine whether the driver has noticed an obstacle ahead based on the gaze point coordinates, whether the driver's cognitive load is too high based on the pupil diameter, and whether the driver is fatigued based on the eyelid closure degree. Based on this information, the intelligent driving algorithm can adjust the output of control commands during shared control transitions—for example, when it detects driver inattention, it appropriately increases the weight of intelligent driving control commands to provide stronger driving assistance; when it detects driver attention has recovered, it gradually decreases the weight of intelligent driving control commands, returning more control to the driver.

[0118] It should be noted that during the simulation, the driving simulation will automatically terminate when the simulated vehicle reaches the target location, experiences a collision, or reaches the preset experimental duration. After termination, the computing device automatically saves the experimental data of the driving simulation, including the time series of vehicle state data, the time series of driving operation data, the time series of eye-tracking data, the curve of the change in control ratio, and the values ​​of driving quality evaluation indicators. The data files can be archived in the format of "Participant ID-Experiment Date-Scenario Type" to generate an experimental information summary, facilitating subsequent data retrieval and comparative analysis. For example, the experimental data can be exported in CSV (Comma-Separated Values) or JSON format, which is convenient for further statistical analysis and visualization using tools such as Python and MATLAB.

[0119] In this embodiment, through methods one and two, the mode switching command can be manually triggered by the driver via a programmable button on the driving peripheral, or automatically triggered by the intelligent driving algorithm through a standardized algorithm interface. Manual triggering is suitable for scenarios where the driver actively decides to switch control modes, while algorithm triggering is suitable for scenarios where the intelligent driving algorithm actively requests to switch control modes based on scenario requirements. These two triggering methods provide a flexible mode switching triggering mechanism for human-machine collaborative control. Through steps S610 to S630, the JSON-formatted scenario configuration file makes parameterized configuration of experimental scenarios possible, allowing for accurate reproduction of the same scenario conditions between different experiments, ensuring the comparability of experimental results. Through steps S710 to S730, the standardized algorithm interface provides a unified access method for intelligent driving algorithms. The four core functions cover the complete closed loop of data acquisition, control adjustment, and command issuance, allowing external algorithms to be deployed and verified without modifying the core code of the simulation platform. Through steps S810 to S820, the eye-tracking data collected by the virtual reality display device can be fed back to the intelligent driving algorithm in real time, enabling the algorithm to adaptively adjust based on the driver's attention distribution, cognitive load, and fatigue state, thereby improving the intelligence level of human-machine collaborative control. By combining scene configuration parameters, standardized algorithm interfaces, and a unified driving quality evaluation index system, the method of this embodiment can conduct a comprehensive and fair comparative verification of different control allocation strategies and adaptive switching algorithms under the same conditions.

[0120] In one feasible implementation, the control methods, evaluation indicators, scenario configurations, and standardized algorithm interfaces given in embodiments one to three above can be uniformly integrated into a complete process for verifying human-machine collaborative control algorithms.

[0121] It should be noted that in algorithm verification scenarios, users first connect the machine control algorithm to be verified to the computing device through a standardized algorithm interface. Different machine control algorithms, such as rule-based traditional control algorithms, deep learning-based end-to-end algorithms, and reinforcement learning-based decision-making algorithms, all connect through the same standardized algorithm interface without requiring modification to the core code of the simulation platform. The algorithm acquires real-time status data and driving operation data of the simulated vehicle through vehicle status acquisition functions and driver status acquisition functions, outputs machine control commands through a vehicle control command sending function, and sends control right adjustment requests to the hierarchical control right management module through a control right allocation ratio setting function.

[0122] After algorithm deployment, users specify parameters such as scenario type, vehicle speed, trigger distance, and weather conditions through scenario configuration files to generate a simulation scenario and initialize the states of the simulated vehicle and traffic participants. During simulation, the computing device executes mode switching control according to the method in Example 1, while simultaneously recording vehicle state data, driving operation data, eye-tracking data, and control weight ratio change data. After the experiment, the values ​​of each driving quality evaluation index in this experiment are calculated according to the driving quality evaluation indicators and methods in Example 2.

[0123] To compare the performance of different algorithms or control allocation strategies, users kept the same scenario configuration file and driving participants, only changing the machine control algorithm to be verified, for example, from algorithm A to algorithm B, or only changing the control allocation strategy, for example, from a linear interpolation strategy to an S-curve strategy. The above experimental process was repeated to obtain the driving quality evaluation index values ​​for different algorithms or strategies under the same conditions. The driving quality evaluation indexes obtained from each experiment were compared horizontally to determine the performance differences of each algorithm across various evaluation dimensions, and the applicability of each control allocation strategy under different algorithms.

[0124] Through the above verification process, the method of this application can conduct multiple independent experiments and horizontal comparisons on different machine control algorithms and different control allocation strategies under the same simulation conditions, realizing comprehensive and fair performance verification of different control allocation strategies and adaptive switching algorithms.

[0125] Combination Figure 2 , Figure 2 This is a block diagram of the overall architecture of the driving simulation control platform provided in this application. The platform is built on the open-source CARLA simulation engine and adopts a two-layer architecture design of "hardware layer - software layer".

[0126] The hardware layer is the physical foundation for system operation, including: computing devices (such as high-performance desktop PCs or workstations) for running the CARLA simulation engine, VR rendering programs, and human-machine collaborative control algorithms; VR display devices (such as HTC VIVE ProEye) for providing the driver with an immersive 3D driving view, while also having built-in eye-tracking sensors to collect the driver's eye movement data in real time (including gaze coordinates, pupil diameter, and eyelid closure); and professional driving peripherals (such as force feedback steering wheels and linear accelerator / brake pedal kits) for simulating the steering resistance and pedal damping characteristics of real driving, and feeding back the driver's steering angle, pedal force, and other driving operation data to the platform.

[0127] The software layer runs on the computing device and includes the following five core functional modules: Standardized experimental scenario generation module: responsible for parsing predefined structured scenario configuration files (such as JSON format), generating corresponding virtual simulation scenarios based on configuration parameters, and automatically completing the initialization settings of the simulated vehicle and traffic participants (such as other social vehicles and pedestrians).

[0128] The hierarchical control management module, a core innovative module of this invention, stores and manages the states of three control modes: "manual control mode," "human-machine shared control mode," and "machine control mode." Upon receiving a mode switching command, this module calculates weighting coefficients in real time within a preset switching duration (e.g., 0.5 seconds), weighting and fusing the "intelligent driving control command" output by the external algorithm with the "driving operation command" generated by the driver to generate the final control command.

[0129] Human-computer interaction data acquisition module: used to synchronously drive and collect driving operation data output by professional driving peripherals and eye-tracking data output by VR display devices, and then format the data for internal use by the platform.

[0130] Algorithm Verification Interface Module: Provides a standardized application programming interface (API) for external human-machine collaborative control algorithms to be verified. This interface includes core functions such as vehicle status acquisition, driver status acquisition, control right allocation ratio setting, and vehicle control command sending. It supports the rapid deployment of external algorithms and allows for closed-loop verification without modifying the platform's core code.

[0131] Data recording and analysis module: used to record all time series data at a fixed frame rate (e.g., 30Hz) during simulation, and automatically calculate preset driving quality evaluation indicators (e.g., steering conflict degree, longitudinal impulse rate, vehicle yaw ratio, etc.) after the experiment, and generate a unified algorithm performance evaluation report.

[0132] The modules communicate with each other through the CARLA underlying API and a custom message bus. The data flow forms a closed loop between the hardware and software modules, realizing complete interaction between "human-vehicle-environment".

[0133] Combination Figure 3 This application also provides a control method for driving simulation based on the above-mentioned driving simulation control platform, the overall process of which includes the following steps: Simulation environment initialization: After the platform starts, the CARLA simulation engine is loaded first, the VR display device and professional driving peripherals are connected, and the core functional modules of each software are initialized to complete the preparation of the operating environment.

[0134] Algorithm Deployment: Users connect their human-machine collaborative control algorithms to this platform through the standardized algorithm verification interface. The platform establishes a communication connection with the algorithm, allowing the external algorithm to begin receiving underlying data and outputting control commands in real time.

[0135] Experimental scenario generation: The platform reads the predefined scenario configuration file, parses out parameters such as scenario type, vehicle speed, trigger distance, and weather conditions, automatically generates virtual simulation scenarios of the specified type (such as sudden braking of the vehicle in front, pedestrian crossing, etc.), and completes the state initialization of the vehicle and other traffic participants.

[0136] Simulation main loop: The platform executes the following actions in a loop at a preset fixed frame rate (e.g., 30Hz): Collect driving operation data from driving peripherals and eye-tracking data from VR devices; Update the physical state of simulated vehicles and traffic participants through the simulation engine; The system sends the current vehicle status, driver status, and eye-tracking data to external algorithms via a standardized interface. Receive intelligent driving control commands returned by external algorithms through the interface, or receive control adjustment requests sent by algorithms through the interface; The hierarchical control management module performs weighted fusion processing on driving operation commands and intelligent driving control commands based on the current control mode and the preset switching time, and generates the final control command to drive the simulated vehicle to run. All experimental data at the current sampling moment are recorded synchronously.

[0137] After the experiment, the data recording and analysis module can automatically organize the recorded experimental data, calculate various driving quality evaluation indicators according to a unified evaluation system, and generate and output an algorithm performance evaluation report containing various evaluation values.

[0138] This application also provides a control device for driving simulation; please refer to... Figure 4 The driving simulation control device includes: The instruction acquisition module 10 is used to receive driving operation instructions and intelligent driving control instructions. The driving operation instructions are determined based on the driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control instructions are generated by the intelligent driving algorithm based on the vehicle status data and driving operation data of the simulated vehicle. The mode confirmation module 20 is used to respond to the received mode switching command and determine the first mode before switching and the second mode after switching, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode. The switching control module 30 is used to transition from the first mode to the second mode within a preset switching time. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation command and intelligent driving control command are weighted and fused. The simulated vehicle is driven based on the final control command obtained from the fusion process. The mode driving module 40 is used to drive the simulated vehicle in the second mode after the preset switching time has ended.

[0139] The driving simulation control device provided in this application, employing the driving simulation control method described in the above embodiments, can solve the technical problem of how to achieve a smooth transition between different control modes in driving simulation, thereby improving the continuity and stability of simulation testing. Compared with the prior art, the beneficial effects of the driving simulation control device provided in this application are the same as those of the driving simulation control method provided in the above embodiments, and other technical features in the driving simulation control device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0140] This application provides a driving simulation control device, which includes: 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the driving simulation control method in the above embodiment 1.

[0141] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a control device suitable for implementing driving simulation in the embodiments of this application. The control device for driving simulation in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5The driving simulation control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0142] like Figure 5 As shown, the control device for driving simulation may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the control device for driving simulation. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the driving simulation control equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a driving simulation control equipment with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0143] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0144] The driving simulation control device provided in this application, employing the driving simulation control method described in the above embodiments, can solve the technical problem of how to achieve a smooth transition between different control modes in driving simulation, thereby improving the continuity and stability of simulation testing. Compared with the prior art, the beneficial effects of the driving simulation control device provided in this application are the same as those of the driving simulation control method provided in the above embodiments, and other technical features of this driving simulation control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0145] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0146] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0147] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the driving simulation control method in the above embodiments.

[0148] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having 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 thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0149] The aforementioned computer-readable storage medium may be included in the control device of the driving simulation; or it may exist independently and not be assembled into the control device of the driving simulation.

[0150] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the driving simulation control device, cause the driving simulation control device to: It receives driving operation commands and intelligent driving control commands. The driving operation commands are determined based on the driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control commands are generated by the intelligent driving algorithm based on the vehicle status data and driving operation data of the simulated vehicle. In response to the received mode switching command, the first mode before switching and the second mode after switching are determined, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode; Within a preset switching time, the system transitions from the first mode to the second mode. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation commands and intelligent driving control commands are weighted and fused. The simulated vehicle is then driven based on the final control commands obtained from the fusion process. After the preset switching time has elapsed, the simulated vehicle will be driven in the second mode.

[0151] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0152] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0153] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0154] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the control method of the above-described driving simulation. This solves the technical problem of how to achieve a smooth transition between different control modes in driving simulation, thereby improving the continuity and stability of simulation testing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method of driving simulation provided in the above embodiments, and will not be repeated here.

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the driving simulation control method described above.

[0156] The computer program product provided in this application solves the technical problem of how to achieve a smooth transition between different control modes in driving simulation, thereby improving the continuity and stability of simulation testing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the driving simulation control method provided in the above embodiments, and will not be repeated here.

[0157] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A control method for driving simulation, characterized in that, The method includes: The system receives driving operation instructions and intelligent driving control instructions. The driving operation instructions are determined based on driving operation data collected by the driving peripherals of the simulated vehicle, and the intelligent driving control instructions are generated by the intelligent driving algorithm based on the vehicle status data of the simulated vehicle and the driving operation data. In response to the received mode switching command, the first mode before switching and the second mode after switching are determined, wherein the first mode and the second mode are different modes among manual control mode, human-machine shared control mode and machine control mode; Within a preset switching time, the system transitions from the first mode to the second mode. Based on the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, the driving operation command and the intelligent driving control command are weighted and fused. The simulated vehicle is then driven based on the final control command obtained from the fusion process. After the preset switching time expires, the simulated vehicle is driven in the second mode.

2. The method according to claim 1, characterized in that, The steps of determining the first mode before the switch and the second mode after the switch include: Obtain the current control mode of the simulated vehicle, use the current control mode as the first mode, and use the control weight ratio corresponding to the current control mode as the first control weight ratio; The control mode indicated by the mode switching command shall be used as the second mode; When the second mode is the manual control mode, the second control ratio is set to the preset manual control ratio value; In the case of the second mode being the human-machine shared control mode, the second control ratio is determined to be the target ratio value corresponding to the shared ratio parameter based on the sharing ratio parameter carried in the mode switching instruction. When the second mode is the machine control mode, the second control ratio is determined to be a preset machine control ratio value.

3. The method according to claim 2, characterized in that, The step of transitioning from the first mode to the second mode within a preset switching time, and weighting and fusing the driving operation commands and the intelligent driving control commands according to the first control ratio corresponding to the first mode and the second control ratio corresponding to the second mode, includes: At each sampling time within the preset switching duration, the intermediate control ratio corresponding to each sampling time is determined based on the preset control allocation strategy, the first control ratio, and the second control ratio. Based on the intermediate control weight ratio corresponding to each sampling time, the driving operation command and the intelligent driving control command corresponding to each sampling time are weighted and fused to obtain the final control command corresponding to each sampling time.

4. The method according to claim 3, characterized in that, Following the step of driving the simulated vehicle in the second mode, the method further includes: Based on the state data and driving operation data of the simulated vehicle within the preset switching time, a driving quality evaluation index is calculated. Based on the driving quality evaluation index, the performance of the combination of the intelligent driving algorithm and the control allocation strategy is evaluated, and an algorithm performance evaluation report is generated. The driving quality assessment indicators include at least one of the following: steering conflict degree, longitudinal pulse rate, vehicle yaw ratio, pedal sudden change energy, speed matching error, cumulative takeover stress, input conflict error, safe braking time index, and trajectory lane error.

5. The method according to claim 1, characterized in that, Prior to the step of responding to the received mode switching instruction, the method further includes: In response to the driver pressing a programmable button on the driving peripheral, the mode switching command is generated; and / or, The system receives a control adjustment request sent by the intelligent driving algorithm through a standardized algorithm interface, and generates the mode switching instruction based on the control adjustment request.

6. The method according to claim 1, characterized in that, Prior to the step of receiving driving operation commands and intelligent driving control commands, the method further includes: Read a predefined scene configuration file to parse and obtain scene configuration parameters, wherein the scene configuration parameters include at least one of scene type, vehicle speed, trigger distance and weather conditions; Generate the corresponding simulation scenario based on the scenario configuration parameters; Initialize the states of the simulated vehicles and traffic participants in the simulation scenario; The scenario types include at least one of the following: sudden braking by the vehicle in front, pedestrian crossing, lane departure, detour through construction zone, and vehicle cutting in.

7. The method according to claim 1, characterized in that, The steps of receiving driving operation commands and intelligent driving control commands include: The driving operation data is collected through the driving peripheral device, wherein the driving peripheral device includes a steering wheel, an accelerator pedal and a brake pedal, and the driving operation data includes at least one of steering angle, accelerator pedal pressure and brake pedal pressure. The vehicle status data and driving operation data are sent to the intelligent driving algorithm through a standardized algorithm interface; Receive the intelligent driving control command returned by the intelligent driving algorithm through the standardized algorithm interface; The standardized algorithm interface provides functions for obtaining vehicle status, obtaining driver status, setting control allocation ratio, and sending vehicle control commands.

8. The method according to claim 7, characterized in that, After the step of sending the vehicle status data and the driving operation data to the intelligent driving algorithm through the standardized algorithm interface, the method further includes: The driver's eye movement data is collected through a virtual reality display device, and the eye movement data includes at least one of the following: fixation point coordinates, pupil diameter, and eyelid closure degree; The eye-tracking data is sent to the intelligent driving algorithm through the standardized algorithm interface.

9. A control device for driving simulation, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the control method for driving simulation as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the driving simulation control method as described in any one of claims 1 to 8.

Images