Vehicle control method, intelligent cockpit and vehicle

Abstract

The application provides a vehicle control method, an intelligent cockpit and a vehicle. The method can comprise: obtaining an initial intention instruction of a target vehicle; wherein the initial intention instruction carries a timestamp; forming a spatio-temporal aligned context data set based on first state data of a multi-source monitoring device of the target vehicle; wherein the first state data comprises a timestamp, and the context data set comprises a plurality of context data; determining a target scene label of the target vehicle based on the context data set; and generating a service instruction for the target vehicle according to the scene label and the initial intention instruction; wherein the service instruction is used to regulate and control the target vehicle.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and more specifically, to a vehicle control method, a smart cockpit, and a vehicle. Background Technology

[0002] With the rapid development of intelligent and connected vehicles, intelligent cockpits have become a key area for the transformation and upgrading of the automotive industry.

[0003] Currently, the operation of intelligent cockpits is easily affected by the time drift of data from multiple sources, which can lead to inaccurate services. Summary of the Invention

[0004] The purpose of this application is to provide a vehicle control method, an intelligent cockpit, and a vehicle that can improve the accuracy of vehicle services.

[0005] In a first aspect, the present invention provides a vehicle control method, comprising: obtaining an initial intent command of a target vehicle; wherein the initial intent command carries a timestamp; forming a spatiotemporally aligned context dataset based on first state data from multi-source monitoring devices of the target vehicle; wherein the first state data includes a timestamp, and the context dataset includes multiple pieces of context data; determining a target scene label of the target vehicle based on the context dataset; and generating a service command for the target vehicle according to the scene label and the initial intent command; wherein the service command is used to regulate the target vehicle.

[0006] In the above implementation, since the obtained first state data is timestamped and the formed context data is spatiotemporally aligned, the impact of time drift of multi-source monitoring equipment is reduced, thus improving the accuracy of the output service instructions and enabling more precise vehicle control.

[0007] In an optional implementation, determining the target scene label of the target vehicle based on the context dataset includes: inputting the context dataset into a dynamic decision model to obtain multiple initial scene labels; and determining the target scene label based on the confidence level corresponding to each initial scene label when there are mutually exclusive labels among the initial scene labels.

[0008] In the above implementation method, preliminary scene labels can be determined based on the model first. On this basis, it can be determined whether there is any exclusion between the initial scene labels. If there is any exclusion, more reliable scene labels can be determined based on the confidence level.

[0009] In an optional implementation, the confidence level of the initial scene label is determined by: determining the confidence level of the initial scene label based on the confidence level of the source monitoring device of the context data corresponding to the initial scene label.

[0010] In an optional implementation, determining the confidence level of the initial scene label based on the confidence level of the source monitoring device corresponding to the context data of the initial scene label includes: performing a first correction on the original confidence level of the source monitoring device corresponding to the context data of the initial scene label based on the environment of the target vehicle to obtain a first corrected confidence level; wherein the original confidence level is pre-configured for each monitoring device; and performing a second correction on the first corrected confidence level based on the delay duration of the context data to obtain the confidence level of each initial scene label.

[0011] In the above implementation methods, depending on the actual scenario, the confidence level can also be corrected based on the actual environment; in addition, the confidence level can also be corrected based on the latency of the actual data, which can make the confidence level based on double correction more reliable.

[0012] In an optional implementation, the method further includes: acquiring second state data of the target vehicle; and combining the second state data with the service instruction to regulate the target vehicle.

[0013] In the above implementation methods, control can also be achieved by combining the current status of the target vehicle with service instructions, which can make the control results more reliable.

[0014] In an optional implementation, obtaining the second state data of the target vehicle includes: obtaining initial state data based on the multi-source monitoring devices; wherein the initial state data includes a timestamp; and if the time difference between the timestamp and the current time exceeds a delay threshold, making a prediction based on the initial state data to obtain predicted current data; wherein the predicted current data serves as the second state data.

[0015] In addition to the above implementation method, the current state can also be predicted adaptively based on the actual possible delay. Combining the prediction with the vehicle regulation can achieve more accurate vehicle control.

[0016] In an optional implementation, the method further includes: broadcasting a synchronization message to the multi-source monitoring devices via the central processing unit of the target vehicle; wherein the synchronization message includes time information; and the multi-source monitoring devices calibrate their local clocks based on the time information and the arrival time of the synchronization message.

[0017] In an optional implementation, broadcasting a synchronization message to the multi-source monitoring devices via the central processing unit of the target vehicle includes: broadcasting a synchronization message to the multi-source monitoring devices via the central processing unit of the target vehicle according to a set time pattern.

[0018] In an optional implementation, forming a spatiotemporally aligned context dataset based on the first state data from the multi-source monitoring devices of the target vehicle includes: acquiring the first state data monitored by the multi-source monitoring devices; spatially aligning the first state data monitored by each monitoring device to obtain spatially aligned state data; and forming a spatiotemporally aligned context dataset based on the spatially aligned state data.

[0019] In an optional implementation, the spatial alignment of the first state data obtained by each monitoring device includes: spatially transforming the first state data obtained by each monitoring device based on the transformation matrix of the specified positions of the monitoring devices and the target vehicle.

[0020] In the above implementation method, spatial transformation is achieved based on various transformation matrices, thereby enabling spatial alignment of various source monitoring devices.

[0021] Secondly, the present invention provides an intelligent cockpit, comprising an intelligent cockpit; the intelligent cockpit includes multi-source monitoring devices and a central processing unit, wherein the multi-source monitoring devices are used to detect various status data of the vehicle in which it is located; and the central processing unit is used to combine the various status data to execute the steps in the above method. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A schematic diagram of an intelligent cockpit provided for an embodiment of this application; Figure 2 A flowchart of a vehicle control method provided in an embodiment of this application; Figure 3 A flowchart illustrating the time calibration involved in the vehicle control method provided in this application embodiment; Figure 4 An optional flowchart of step 220 of the vehicle control method provided in an embodiment of this application; Figure 5 An optional flowchart of step 230 of the vehicle control method provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] With the rapid development of automotive intelligence and connectivity, the intelligent cockpit has become a key area for the transformation and upgrading of the automotive industry. The intelligent cockpit integrates various advanced technologies, aiming to provide drivers and passengers with a more convenient, comfortable, safe, and personalized driving and riding experience. It integrates multiple subsystems such as in-vehicle infotainment systems, driver assistance systems, and human-machine interaction systems, becoming the core embodiment of automotive intelligence. The in-vehicle desktop, as the direct interface between the intelligent cockpit and the user, carries important functions such as information display and function control. Achieving efficient data interaction and collaborative operation between the intelligent cockpit and the in-vehicle desktop is crucial for improving the overall vehicle intelligence level and user satisfaction.

[0027] Intelligent cockpits typically use data collected from various sensors to identify the vehicle's surroundings and provide optional services. The standardized dataset can then be pushed to the vehicle's desktop system in real time. However, in practice, several issues arise: the system is susceptible to timestamp drift and feature conflicts from multi-source sensor data, leading to label splitting. Since intelligent cockpits collect data from various vehicle sensors—such as vehicle operating status (speed, acceleration), environmental perception (cameras, radar, etc.), and user behavior (eye tracking, voice commands)—the sources of this data may differ in data acquisition frequency and transmission latency. For example, a camera might have a frame rate of 30fps, the CAN bus data update cycle 100ms, and the radar detection frequency 10Hz. In extreme scenarios like high-speed driving, even a small time difference (50ms) can cause related data collected at the same moment to correspond to different physical time points. For instance, when a vehicle is making a sharp turn, the lateral acceleration of the vehicle changes significantly, and this drastic change in the vehicle's driving state should be detected. However, if there is a delay in camera data transmission, it may still output a "straight road" image before the turn, while the radar has already detected an approaching obstacle. In this situation, there may be contradictory recognition results; for example, it may recognize "smooth driving" but also recognize "obstacle warning." These contradictions may cause the vehicle to fail to react correctly, seriously affecting driving safety and user experience.

[0028] Based on the above research, the embodiments of this application can provide a vehicle control method, a smart cockpit, and a vehicle, which can more accurately control the vehicle. The vehicle control method provided by this application is described below in conjunction with several scenarios.

[0029] To facilitate understanding of this embodiment, the vehicle and the smart cockpit that implement the vehicle control method disclosed in this application will first be introduced.

[0030] like Figure 1 As shown in the figure, this application embodiment provides a smart cockpit. The smart cockpit 100 may include: a multi-source monitoring device 110 and a central processing unit 120.

[0031] The multi-source monitoring device 110 is used to detect various status data of the vehicle in question.

[0032] The monitoring equipment 110 may include vehicle speed detection equipment, image acquisition equipment, radar, eye-tracking sensors, infrared eye trackers, etc. The vehicle speed detection equipment may be a speed sensor, an acceleration sensor, a vehicle body IMU (Inertial Measurement Unit) sensor, etc.

[0033] For example, the status data that each monitoring device 110 can obtain includes vehicle operating status data, environmental perception data, and user behavior data. Vehicle operating status data may include vehicle speed, acceleration, etc. Environmental perception data may include data such as the position and orientation of obstacles in the environment. User behavior data includes data such as user eye tracking and voice commands.

[0034] The aforementioned central processing unit 120 can be used to combine various state data to execute the steps in the vehicle control methods of the various embodiments of this application.

[0035] A smart cockpit can also include a body control module, an ADAS (Advanced Driver Assistance Systems Domain Controller), and cockpit sensors. These cockpit sensors can be used to monitor the status of the vehicle's cockpit. The ADAS domain controller is the core computing unit, responsible for integrating sensor data, running algorithms, and controlling actuators to achieve Level 1-Level 3 autonomous driving functions.

[0036] In practice, the smart cockpit can include more sensors capable of monitoring different data as the number of functions required increases.

[0037] This application also provides a vehicle that may include the aforementioned smart cockpit.

[0038] Optionally, the vehicle may also include a vehicle-mounted desktop, which can be used to receive the intention commands of the driver or passengers. The vehicle-mounted desktop can also output relevant prompts.

[0039] The smart cockpit and vehicle in this embodiment can be used to execute various steps in the methods provided in the embodiments of this application. The implementation process of the vehicle control method is described in detail below through several embodiments.

[0040] Please see Figure 2 This is a flowchart of a vehicle control method provided in an embodiment of this application. The vehicle control method provided in this application can be applied to a vehicle, which may be equipped with a smart cockpit, and the steps in the vehicle control method can be executed by various components in the smart cockpit. The following will describe... Figure 2 The specific process shown will be explained in detail.

[0041] Step 210: Obtain the initial intent command of the target vehicle.

[0042] Optionally, in response to the user's touch, voice, physical button or eye-tracking operation on the current interactive interface on the vehicle's desktop, the system can parse the operation object and operation type, and generate an initial intent command carrying a timestamp and operation semantics.

[0043] For example, when a user performs touch operations on the vehicle's infotainment system, the coordinates of the touch point can be obtained first through the touchscreen driver. Taking a common capacitive touchscreen as an example, its working principle utilizes the capacitive coupling between the human body's electric field and the touchscreen surface. When a finger touches the touchscreen, it changes the capacitance distribution on the touchscreen, which is then detected by the touchscreen controller. After obtaining the touch point coordinates, they can be matched with predefined interface elements based on the interface layout information of the vehicle's infotainment system. For example, in a map application interface, coordinate matching determines whether the user clicked a location marker on the map or a zoom, pan, or other operation button on the map. Simultaneously, the intelligent cockpit system can record the duration of the touch operation and determine whether the operation type is a click or a long press by judging whether the touch duration exceeds a preset long-press threshold (e.g., 500 milliseconds). For swiping and zooming operations, the intelligent cockpit system can track the movement trajectory of the touch point in real time, calculating parameters such as the swiping distance, direction, and zoom ratio to accurately identify the operation type. Finally, the identified operation object identifier (such as the unique ID of the location marker and the name of the operation button), operation type code (0x01 for click, 0x02 for long press, 0x03 for swipe, and 0x04 for zoom), operation timestamp, and source channel information (identified as touchscreen) are integrated to generate the initial intent instruction. In one instance, the format of this initial intent instruction can be: [operation object identifier, operation type code, timestamp, source channel information]. For example, a smart cockpit can include an in-vehicle voice recognition engine that uses deep learning-based voice recognition technology to process user-input voice signals. The target vehicle can be equipped with a microphone to collect voice signals, which are then preprocessed to improve their quality. This preprocessing may include noise reduction and filtering. The preprocessed voice signal can then be converted into acoustic feature vectors. Commonly used acoustic features include Mel-frequency cepstral coefficients (MFCC) and linear predictive cepstral coefficients (LPCC). These acoustic feature vectors are input into a language recognition model, which, through training and learning speech patterns and language knowledge, converts the acoustic feature vectors into text information. Natural language understanding technology can then be used to perform semantic analysis on the text. Through syntactic analysis, the grammatical relationships between words are determined, and the grammatical structure of sentences is constructed. Finally, semantic matching and knowledge graph technologies are used to extract intent entities, thereby determining the operation object and operation type. The parsed results are then used to generate an initial intent command in a format that conforms to the initial intent command. For example, the initial intent command can also be generated based on the operation of the error key. The intelligent cockpit system can be connected to the key via hardware circuitry. When a key is pressed, the circuit generates an electrical signal. After detecting this signal, the system determines the operation object and operation type based on a pre-defined mapping relationship between key IDs, operation objects, and operation types. The initial intent command is then generated according to the pre-defined format. For example, the eye-tracking sensor installed inside the target vehicle typically uses a combination of an infrared camera and an infrared emitter. It tracks the user's gaze by emitting infrared light and capturing the infrared light reflected from the human eye. Image recognition technology is used to detect the position of the eyes and the direction of the pupils. By calculating the position and angle of the pupils in the image, combined with the interface layout of the vehicle's infotainment system and the camera's calibration parameters, the focal area of ​​the user's gaze on the infotainment system's interface is determined. For example, by converting image coordinates to logical coordinates on the infotainment system's interface, it is determined that the user is gazing at a specific song in a music playlist. Simultaneously, the duration of the user's gaze is recorded. When the gaze duration exceeds a preset gaze trigger threshold, a corresponding operation is triggered. Based on the preset gaze trigger operation type, the operation type is determined to be playing the song. An initial intent command can be generated according to a preset format based on user annotations. Optionally, the generated initial intent instruction may carry a timestamp. This timestamp may be in the microsecond range.

[0044] Step 220: Based on the first state data of the multi-source monitoring equipment of the target vehicle, a spatiotemporally aligned context dataset is formed.

[0045] The first state data includes a timestamp, and the context dataset includes multiple pieces of context data.

[0046] Optionally, the multi-source monitoring equipment for the target vehicle can use the Precision Time Protocol (PTP) to timestamp the acquired first state data.

[0047] The various monitoring devices can also achieve coordinate unification based on coordinate transformation.

[0048] The aforementioned context dataset can be a context dataset that satisfies spatiotemporal alignment.

[0049] For example, the first state data may include data such as vehicle speed, lateral acceleration, obstacle distance, and user's line-of-sight focus position. Time alignment of the state data can be achieved based on the timestamps of each state data point. For instance, the time-stamped speed data of the target vehicle at a certain moment, the spatiotemporally aligned obstacle distance data calculated from the state data obtained from the image acquisition device and radar, and the user's line-of-sight focus position data at the same moment can be integrated to form a context dataset. This context dataset can provide an accurate data foundation for subsequent analysis and processing. For example, vehicle speed data can include vehicle speed and lateral acceleration, both of which can be acquired via the CAN bus and can carry a timestamp. The timestamp ensures that the vehicle's state data is aligned in the time dimension with the data collected by monitoring equipment regarding the vehicle's surroundings. Secondly, obstacle distance information detected by radar can be mapped to the target vehicle's body coordinate system using a spatial transformation matrix, ensuring that this location data is spatially consistent with the vehicle's autonomous state. Additionally, the coordinates of the user's gaze focus can be obtained from a gaze-tracking sensor, and after projection along the optical axis and calculation using in-vehicle sensor installation parameters, this data is also transformed into a unified coordinate framework. All data, after processing, is combined into a structured vector-based spatiotemporally aligned context dataset, which can be represented as: ; Where Ct represents the context dataset at time t; This represents the longitudinal velocity of the target vehicle at time t; This represents the lateral acceleration of the target vehicle at time t; Indicates the distance between the target vehicle and the nearest obstacle; This represents the three-dimensional position vector of the user's gaze point on the target vehicle in the vehicle coordinate system.

[0050] In this embodiment, all variables in the context set can have microsecond-level timestamps, ensuring that the context set can serve as valid input in the dynamic decision-making model for the reasoning process of intent parsing and service triggering logic. This precise spatiotemporal consistency not only enhances the system's responsiveness to complex scenarios but also lays a highly reliable input foundation for subsequent prediction compensation and collaborative operations.

[0051] Step 230: Based on the context dataset, determine the target scene label of the target vehicle.

[0052] Optionally, the context dataset can be identified using scene recognition models to obtain one or more scene labels. These scene labels can be used to represent the environment in which the target vehicle is located, the driving state of the target vehicle, etc. For example, scene labels may include: low-speed parking, smooth driving, high-speed turning, pedestrian warning, obstacle warning, etc.

[0053] Step 240: Generate service instructions for the target vehicle based on the scene tags and initial intent instructions.

[0054] Service commands are used to control the target vehicle. They can be used to avoid potential obstacles, such as enhancing steering assistance during sharp turns. Service commands can also be used to provide services requested by the driver or passengers, such as playing music or displaying navigation.

[0055] For example, the target scene label and initial intent command can be input into the dynamic mapping engine to match the optimal service combination in the preset scene rule base and generate a service command. This service command may include information such as the target data source identifier, operation service interface, and compensation parameters.

[0056] In this embodiment, in order to make vehicle control more accurate, when controlling the vehicle, the current state of the target vehicle can be predicted based on the obtained state data, and the target vehicle can be regulated based on the predicted current state of the target vehicle.

[0057] Optionally, after inputting the target scene label and initial intent command into the dynamic mapping engine, a preset scene rule base is traversed. Each rule in the scene rule base can consist of a trigger condition, a corresponding target data source, an operation service interface, and compensation parameters. For example, a rule in the rule base may include: when the target scene label includes high-speed cornering and the confidence level is >0.8, and the initial intent command is to adjust the vehicle steering, the target data source can be the ADAS domain controller, the operation service interface is the steering wheel torque control interface, and the compensation parameter is to increase the lateral acceleration threshold by 20%. The dynamic mapping engine matches the final scene label with the trigger condition of the rule. When a match is successful, the target data source, operation service interface, and compensation parameters defined by the rule are determined, and a service command is generated. When multiple rules match, the optimal rule is selected based on the preset priority or confidence score of the rules. For example, if rule A has a high priority and rule B has a low priority, and the target scene label matches both rule A and rule B, rule A is selected. By using the methods described above, the spatiotemporally aligned context dataset can make subsequent services generated based on this data more accurate, thereby improving the accuracy of vehicle control.

[0058] To improve spatiotemporal synchronization, the method in this embodiment may further include steps 310 and 320. In this embodiment, as... Figure 3 As shown, steps 310 and 320 can be performed at least once before step 210, and time calibration can also be achieved through steps 310 and 320 during the execution of steps 210 to 240.

[0059] Step 310: Broadcast a synchronization message to the multi-source monitoring equipment through the central processing unit of the target vehicle.

[0060] The synchronization message includes time information.

[0061] Step 320: The multi-source monitoring device calibrates its local clock based on time information and the arrival time of the synchronization message.

[0062] Step 310 above may include: broadcasting a synchronization message to the multi-source monitoring equipment through the central processing unit of the target vehicle according to a set time pattern.

[0063] The set time pattern can be to execute steps 310 and 320 once every specified time interval.

[0064] For example, the central processing unit of the smart cockpit can act as the PTP master clock, periodically broadcasting synchronization messages to all critical subsystems via the vehicle Ethernet. These subsystems include the body control module, ADAS domain controller, and monitoring device nodes such as cameras, radar, and microphone arrays within the cockpit. When these monitoring device nodes receive the synchronization message from the master clock, they record the arrival time of the message in real time and calculate the offset between their local time and the master clock by combining it with their local clock, thereby performing dynamic correction to ensure that the entire system maintains time consistency at the microsecond level.

[0065] After time synchronization is completed, a unified timestamp can be applied to the data obtained from each monitoring device. For example, each image frame, each vehicle status information from the CAN bus, and each radar point cloud scan are timestamped to ensure that the error is controlled within 100 microseconds. Taking a lane change operation as an example, the time when the system detects lane line deviation through the binocular camera and the time when the radar senses a vehicle approaching from the side and rear can be precisely aligned. This provides a strict timing basis for the parsing of the initial intent command and the response to the service command, significantly improving the accuracy of the interaction logic and the stability of the system response.

[0066] In this embodiment, the central processing unit (CPU) can broadcast synchronization messages to each monitoring device node via the in-vehicle Ethernet at a fixed period, such as once per second. The synchronization message contains the current time information of the master clock. Upon receiving the synchronization message, each node uses a hardware timer to precisely record the message arrival time. Then, each monitoring device node calculates the offset between its own clock and the master clock by comparing the time with the master clock's time. For example, assuming the time in the synchronization message sent by the master clock is T1, and a monitoring device node receives the synchronization message at time T2, and the node records the reception time as T3, then the clock offset calculated by that node is (T3-T2)+T1. Each node dynamically corrects its local clock based on the calculated offset, ensuring that the error between each node's clock and the master clock is controlled within 100μs.

[0067] In one alternative implementation, such as Figure 4 As shown, step 220 above may include steps 221 to 223.

[0068] Step 221: Obtain the first state data monitored by the multi-source monitoring equipment.

[0069] Step 222: Spatial alignment is performed on the first state data obtained from each monitoring device to obtain spatial alignment state data.

[0070] Step 223: Based on the spatial alignment state data, form a spatiotemporal aligned context dataset.

[0071] Step 222 above may include: spatially transforming the first state data obtained by each monitoring device based on the transformation matrix of the monitoring device and the specified location of the target vehicle.

[0072] The designated location of the target vehicle can be the target vehicle's center of mass, the target vehicle's center position, the target vehicle's driver's position, etc.

[0073] Taking the vehicle's center of gravity as an example, an ISO 8855 coordinate system is established with the vehicle's center of gravity as the origin. This coordinate system defines the coordinate axes for the vehicle's front-to-back, left-to-right, and up-to-down directions. For image acquisition equipment data, a pre-calibrated intrinsic parameter matrix is ​​used to convert the image pixel coordinates of the image acquisition equipment into vehicle coordinate system coordinates. The intrinsic parameter matrix includes parameters such as the focal length and principal point position of the image acquisition equipment. These parameters can compensate for spatial differences caused by different installation positions and angles of the image acquisition equipment.

[0074] These transformations unify image acquisition equipment and radar data into the vehicle body coordinate system, achieving spatial alignment. In one example, a unified spatial reference frame can be established, namely the ISO8855 vehicle coordinate system with the vehicle's center of gravity as the origin, the front as the x-axis, the left as the y-axis, and the vertically upward as the z-axis. This coordinate system provides a unified spatial reference for different types of sensors. In image acquisition equipment data processing, the coordinates of two-dimensional pixels in the image can be distorted and projected using the intrinsic parameters of the image acquisition equipment to restore the line-of-sight vector in three-dimensional space. Then, combined with the installation pose of the image acquisition equipment on the vehicle body, it can be mapped to three-dimensional coordinate points in the vehicle coordinate system. The conversion formula can be expressed as: ; in, This indicates the position of the image captured by the image acquisition device in the vehicle body coordinate system. Represented as normalized image pixels, K represents the intrinsic parameter matrix of the image acquisition device; and These represent the rotation and translation relationships between the image acquisition device and the vehicle body coordinate system.

[0075] Radar point cloud data is typically acquired in polar coordinates. After converting it to Cartesian coordinates, it is transformed from the radar coordinate system to the vehicle coordinate system using a rotation matrix and translation vector of the radar installation position. The specific calculation is as follows: ; in, This indicates the position of the point in the vehicle body coordinate system to which the data collected by the radar has been converted; Indicates the position of a point in the radar local coordinate system; and These represent the rotation and translation of the radar to the vehicle's coordinate system, respectively. Through the above transformation, the system uniformly maps the perception data from the image acquisition device and the radar to the vehicle's own reference coordinate system, achieving spatial alignment of the perception data of the vehicle's surrounding environment. This makes the information output by different sensors comparable in three-dimensional space, providing a precise spatial basis for subsequent scene recognition and intent interpretation.

[0076] Through the above steps, multiple dimensions of time and space alignment can be achieved, enabling the obtained data to better represent the state of the target vehicle at each moment.

[0077] Considering factors such as data latency and varying accuracy of monitoring equipment in different environments, the accuracy of scene labels generated directly based on dynamic decision-making models may contain some deviations. Therefore, if... Figure 5 As shown, step 230 above may include steps 231 and 232.

[0078] Step 231: Input the context dataset into the dynamic decision model to obtain multiple initial scene labels.

[0079] Optionally, a dynamic decision model can be matched for each context dataset to identify the label corresponding to the context data. Alternatively, the context dataset can be input as a whole into a dynamic decision model to output a set of scene labels.

[0080] For example, key features can be extracted from a spatiotemporally aligned contextual dataset and input into a lightweight dynamic decision model to generate initial scene labels.

[0081] If there are mutually exclusive tags in each initial scene tag, proceed to step 232.

[0082] In one instance, the determined spatiotemporally aligned context dataset might include: vehicle speed of 100 km / h, lateral acceleration of 0.4g, steering wheel angle of 40°, and obstacle distance of 30m. Key feature vectors can be extracted from this data: vehicle speed > 80 km / h, lateral acceleration > 0.3g, steering wheel angle > 30°, and obstacle distance < 50m. These key feature vectors are then input into a pre-trained lightweight decision tree model, which analyzes and judges based on predefined classification rules. For example, the predefined rule in the decision tree model is: when vehicle speed > 80 km / h, lateral acceleration > 0.3g, and steering wheel angle > 30°, output the label "high-speed cornering"; when obstacle distance < 50m, output the label "obstacle approaching". Therefore, the dynamic decision model outputs the initial scene label combination as [high-speed cornering, obstacle approaching]. Step 232: Determine the target scene label based on the confidence level corresponding to each initial scene label.

[0083] The target scene label can be determined based on the confidence level of each initial scene label.

[0084] If the difference in confidence between two mutually exclusive scene labels is greater than the confidence threshold, the initial scene label with the higher confidence can be used as the target scene label.

[0085] If the difference in confidence scores between two mutually exclusive scene labels is no greater than a confidence threshold, the next time-step context dataset can be obtained by prediction based on the currently acquired context dataset. A new scene label is then determined based on the next time-step context dataset. The method for determining the new scene label based on the next time-step context dataset can be found in step 230 and its sub-steps described above.

[0086] Alternatively, the Kalman filter method can be used to predict the context dataset for the next time step.

[0087] In one example, the confidence threshold can be 0.3, and the initial scene label combination is [Smooth Driving, Obstacle Approaching], which results in a logical conflict. The real-time confidence weights of the data sources associated with the conflicting labels are extracted. Assuming "Smooth Driving" is mainly determined by data from the image acquisition device, its confidence weight is 0.35, and "Obstacle Approaching" is determined by millimeter-wave radar data, its confidence weight is 0.8. Comparing the weight difference, 0.8 - 0.35 = 0.45 ≥ 0.3, the higher-weighted label "Obstacle Approaching" is adopted, and thus "Obstacle Resolution" can be used as the target scene label.

[0088] If the confidence difference is less than 0.3, the prediction of the state at the next moment can be initiated to obtain the context dataset, so as to further determine the scene label based on step 230 above.

[0089] In one optional implementation, the confidence level of the initial scene label is determined by: step 410, determining the confidence level of the initial scene label based on the confidence level of the source monitoring device of the context data corresponding to the initial scene label.

[0090] For example, the confidence level corresponding to the initial scene label can be determined based on the reliability of its data source.

[0091] For example, the data on which the initial scene label is based may be collected by one of the monitoring devices, and the confidence level of the monitoring device can be used as the confidence level of the initial scene label.

[0092] The confidence level of monitoring equipment can be determined based on factors such as its accuracy and the timeliness of data collection and transmission.

[0093] In one example, the monitoring device may include radar, which may be millimeter-wave radar. Because millimeter-wave radar has high accuracy, its confidence level can be set to a relatively high value, for example, its confidence level can be set to 0.9.

[0094] In one example, the monitoring device may include an image acquisition device, such as a binocular camera, which has relatively high accuracy but is not as accurate as millimeter-wave radar, and its confidence level can be set to 0.7; in one example, the monitoring device may include a vehicle body IMU sensor, and its confidence level can be set to 0.85; in one example, the monitoring device may include an eye-tracking sensor, and its confidence level can be set to 0.75.

[0095] Different environments may affect the accuracy of monitoring equipment. Therefore, step 410 above may include steps 411 and 412.

[0096] Step 411: Based on the environment in which the target vehicle is located, perform a first correction on the original confidence level of the source monitoring device of the context data corresponding to the initial scene label to obtain a first corrected confidence level.

[0097] The initial confidence level is pre-configured for each monitoring device. The initial confidence level can be configured based on the accuracy of each monitoring device. Higher accuracy results in a higher initial confidence level.

[0098] In some environments, the accuracy of monitoring equipment may be affected. For example, assuming the current weather is rainy or foggy, the confidence levels of each monitoring device can be corrected based on the environmental impact. For instance, rainy or foggy weather can affect the clarity of image acquisition equipment, so the confidence level of the image acquisition equipment can be multiplied by an environmental correction factor less than one. For example, the environmental correction factor could be 0.5, in which case the confidence level of the image acquisition equipment becomes 0.35.

[0099] In this embodiment, when the target vehicle is in a relatively good environment, the environmental correction factor can be 1.

[0100] Step 412: Based on the delay duration of the context data, perform a second correction on the first corrected confidence level to obtain the confidence level of each initial scene label.

[0101] For example, the data freshness weight can be determined based on the data latency duration, and then the data freshness weight can be multiplied by the first corrected confidence level to obtain the confidence level of the initial scene label.

[0102] If there is no data delay, the data freshness weight can be 1.

[0103] In one example, the data latency of the data source for a certain initial scene label is 20ms. According to the data freshness weight formula, the data freshness weight of this data source is calculated to be 0.67. Multiplying the original confidence score, the environment correction factor, and the data freshness weight yields the final confidence score of the data source for each initial scene label. The following section uses actual data to describe the entire process of determining target scene labels.

[0104] Having obtained the context dataset, key feature vectors describing the vehicle's dynamic state and environmental elements are extracted. For example, these may include features such as the current vehicle speed, lateral acceleration, steering wheel angle, and distance to obstacles ahead. Before executing the vehicle control method of this application, various threshold conditions can be set, including: vehicle speed greater than 80 km / h, lateral acceleration greater than 0.3 times the gravitational acceleration, steering wheel angle greater than 30 degrees, and distance to obstacles less than 50 meters. When these conditions are met, it indicates that the vehicle is in a high-speed driving scenario with a significant lateral change of direction and an approaching target ahead.

[0105] These features can be combined and used as input vectors for dynamic decision-making models: .

[0106] in, This represents the speed of the target vehicle at time t; This represents the lateral acceleration of the target vehicle; This represents the current steering wheel angle of the target vehicle at time t; This input vector represents the distance between the target vehicle and the obstacle ahead. It is fed into a lightweight decision tree classification model, which performs node splitting and judgment based on different feature combinations, ultimately generating a set of initial scene labels at the output layer. For example, when the conditions of high vehicle speed, large-angle steering, and close-range obstacles are simultaneously met, the system outputs the labels "high-speed cornering" and "obstacle approaching"; while when the vehicle speed is below 10 km / h, the steering wheel angle changes slowly, and a slow-moving target is detected nearby, the model may output the labels "low-speed parking" and "pedestrian warning". In the process of determining the initial scene labels, intelligent labeling of the target vehicle's current driving situation can be achieved through data recognition, providing a clear semantic basis for subsequent confidence-weighted arbitration and service mapping.

[0107] Furthermore, the information from various data sources needs to be weighted by confidence level to ensure that the more reliable perception results are prioritized when there are logical conflicts in the multi-label outputs. First, each type of sensor is assigned a basic confidence weight: millimeter-wave radar has a base weight of 0.9, binocular cameras 0.7, vehicle-mounted IMUs 0.85, and eye-tracking sensors 0.75. Then, an environmental correction factor is introduced based on the current environmental conditions to dynamically adjust the sensor weights. For example, in rainy or foggy weather, the millimeter-wave radar weight is multiplied by 0.8 to obtain an actual weight of 0.72; the binocular camera weight is multiplied by 0.5 to become 0.35 in rainy or foggy conditions; and in low-light nighttime conditions, the weight is further reduced to 0.21. The IMU sensor weight is multiplied by 0.9 to become 0.765 on bumpy roads, and the eye-tracking sensor weight is adjusted to 0.525 in strong glare scenarios. Based on the varying complexity of the actual environment, more environmental correction factors can be set for various monitoring devices under different conditions.

[0108] The time delay of each data point is measured in real time, and its confidence level is further adjusted using an exponential decay function. The specific formula for calculating the data freshness weight can be expressed as follows:

[0109] in, This indicates the time delay from data packet acquisition to processing, in milliseconds. For example, with a delay of 50 milliseconds, the data freshness weight is e. -1The value is approximately 0.3679. A greater delay corresponds to a lower weight for data freshness, reflecting the strict requirements for timeliness. Finally, the original confidence level, environmental correction factor, and data freshness weight are multiplied to obtain the comprehensive confidence level of each data source for arbitrating the initial scene label at the current moment. This constitutes the priority selection criterion among the output labels of the dynamic decision-making model, thereby improving the robustness and rationality of multimodal perception fusion.

[0110] In the conflict arbitration mechanism, decisions are made to correct logically mutually exclusive situations in the initial scene label combinations, ensuring the consistency and credibility of the scene labels. For example, when semantically conflicting labels such as "smooth driving" and "obstacle approach" appear simultaneously in the initial scene labels, the data sources on which these two labels rely are analyzed back, and their confidence weights are extracted after correction and time-sensitivity attenuation processing at the current moment. For example, the "smooth driving" label mainly relies on IMU sensor data, while the "obstacle approach" label mainly relies on millimeter-wave radar and camera data. The system quantitatively compares the difference in their respective confidence weights. If the difference is greater than or equal to 0.3, the label with higher confidence is directly adopted, and the weaker label is discarded, thus quickly completing the arbitration.

[0111] If the confidence weight difference is less than 0.3, it indicates uncertainty in the current state, and the prediction correction process can proceed. A Kalman filter is then used to predict the state of key dynamic parameters such as acceleration and relative velocity to obstacles. Here, the Kalman filter is used to evaluate the current state variable x. t Make a prediction: ; in, For the current state estimate, ut is the control input, and A and B are the state transition and control matrices, respectively. The system uses the predicted values... The corresponding feature vectors are recalculated and input into the dynamic decision model again to determine whether there is label convergence in the next moment, thereby updating the arbitration result.

[0112] The final output label not only contains semantic content but also includes a comprehensive confidence score. For example, during a high-speed lane change, the system might output the label "High-speed cornering (confidence 0.88)," indicating that the current label is a stable inference result based on multiple high-confidence data sources and consistent state predictions. By introducing a confidence difference threshold judgment and a state prediction-assisted arbitration mechanism, the system enhances its robustness in recognizing ambiguous and multi-source conflict scenarios, effectively suppressing the risk of false triggering caused by abnormal perception results.

[0113] The above implementation logic makes the obtained scene labels relatively reliable, which also increases the credibility of subsequent service instructions and improves the accuracy and reliability of vehicle control.

[0114] Upon receiving a service instruction, the target vehicle can be precisely controlled based on that instruction. Therefore, the method of this application may further include steps 250 and 260.

[0115] Step 250: Obtain the second state data of the target vehicle.

[0116] This second state data can characterize the state of the target vehicle when it needs to execute a service command.

[0117] Step 260: Combine the second state data and service instructions to adjust the target vehicle.

[0118] In one instance, when the final target scenario label contains "high-speed cornering" and the confidence level exceeds 0.8, the dynamic mapping engine will trigger an emergency avoidance priority rule, prioritizing the routing of data commands to the ADAS domain controller with real-time trajectory response capabilities. At this point, the target data source is explicitly pointed to the ADAS domain controller, which provides high-frequency lane curvature fitting and steering path calculation capabilities. The corresponding operation service interface selects the steering wheel torque control channel, allowing the vehicle's infotainment system to directly adjust the torque output of the electric power steering, thereby stabilizing the lateral attitude of the target vehicle and improving stability and safety margin during cornering.

[0119] To make the system response more proactive, a set of compensation parameters can be injected into the service command, specifically for dynamically adjusting the lateral acceleration safety threshold. For example, in the original settings, the upper limit for lateral acceleration control is set to the safety threshold. In high-confidence high-speed curve scenarios, this threshold can be appropriately increased, for example, by 20%, meaning the mapping logic is adjusted as follows: ; in, This represents the maximum tolerable lateral acceleration under the current strategy, used as a path feasibility constraint for the trajectory optimization module. This adjustment allows the strategy to relax the yaw force limit within the limits of vehicle stability control capabilities, ensuring smoother avoidance or lane change processes while preventing accidental ESC braking intervention and maintaining handling continuity.

[0120] When outputting service commands, the dynamic mapping engine can structurally encapsulate the target data source, service interface, and compensation parameters, and send them to the controller network via a high-speed communication channel, achieving closed-loop linkage between perception, decision-making, and execution. This mechanism enhances the responsiveness to highly dynamic scenarios, transforming the vehicle's desktop system from an information presentation platform into a central node for coordinating proactive driver assistance behaviors.

[0121] During the cross-domain collaborative execution phase, the entire intelligent cockpit system can drive joint responses between the intelligent cockpit and the execution subsystem based on the multimodal initial intent commands parsed in the preceding steps, the spatiotemporally aligned context dataset, and the final target scene labels. For example, if the current scenario is "high-speed cornering," the intelligent cockpit identifies it as a high-dynamic-risk condition and has already generated a service command containing enhanced lateral assistance through step 240 mentioned above. For instance, the vehicle's desktop interface instantly displays an interactive prompt in the floating warning area: "Sharp turn! Automatically enhance steering assist," simultaneously triggering the voice broadcast module to improve the driver's or passengers' perception of the current system behavior. This prompt window occupies the center of the main instrument panel and uses high-contrast colors and a three-second flashing prompt to ensure information accessibility.

[0122] Furthermore, a set of encapsulated torque control commands can be sent to the Electric Power Steering (EPS) system via the CAN bus. This command structure includes the current timestamp, steering demand value, and dynamic compensation parameters. The EPS system adjusts its power assist output based on the received torque target value, and its control logic incorporates steering torque... It consists of basic requirements and compensation gains: ; in, Indicates the basic steering torque requirement; This indicates the current lateral acceleration of the target vehicle; This indicates the dynamic assist gain coefficient. This mechanism ensures that under conditions of high yaw load, the system automatically applies additional auxiliary torque, enhancing the driver's confidence in steering wheel control.

[0123] Optionally, step 250 described above may include steps 251 and 252.

[0124] Step 251: Obtain initial state data based on multi-source monitoring equipment.

[0125] The initial state data includes timestamps.

[0126] Step 252: If the time difference between the timestamp and the current time exceeds the delay threshold, make a prediction based on the initial state data to obtain the predicted current data.

[0127] In this context, the predicted current data serves as the second state data.

[0128] Alternatively, Kalman filtering can be used to make predictions based on the initial state data to obtain predictions for the current data.

[0129] To address the perception gap caused by data lag in critical scenarios, a state-space model is constructed for image acquisition devices or other monitoring equipment experiencing transmission delays. The Kalman filter can be modeled using a three-dimensional state vector, where the three states represent the target object's position, velocity, and acceleration in the vehicle body coordinate system, and can be denoted as... The target object can be an object in an image captured by an image acquisition device. This object could be an obstacle, or other vehicles around the target vehicle.

[0130] The observation model is set as follows ; in, H represents the actual target location observed by the image acquisition device; H represents the observation matrix, used to extract observable components from the state vector. This represents Gaussian observation noise.

[0131] The continuous positional changes of the target can be extracted from the valid images acquired by the image acquisition device over the past three frames, and the average velocity and acceleration can be calculated as the current control input. Then, the target state at the corresponding moment in the delayed frame is predicted using the state transition equation, expressed as:

[0132] in, The current predicted state is represented by F; the state transition matrix is ​​represented by F, which, combined with the vehicle sampling period, represents the dynamic evolution relationship of the system; and the control input matrix is ​​represented by B. This represents the control vector, which typically includes the predicted acceleration or vehicle motion state at the current moment. After prediction, the system weights and fuses the predicted value with the actual observation data according to their respective confidence levels, and outputs the final value used for obstacle position estimation.

[0133] To construct a traceable chain of system behavior, after the service instruction is executed, data such as the current target scenario label, label conflict events, the arbitration process of label conflicts, and the service instruction can be structured into a record and uploaded to the cloud analysis platform in real time via a TLS encrypted channel. The record content includes event timestamps, involved labels, data source weight distribution, Kalman prediction state, and service items matched by mapping rules.

[0134] In this embodiment, the recorded data can support subsequent model training and optimization, fault tracing, and driving behavior research. Through the collaborative execution mechanism, the vehicle system no longer only plays the role of information display, but also integrates perception, control, and feedback to build a highly robust closed-loop collaborative path among multi-domain systems.

[0135] The cloud-based analytics platform accumulates a large amount of historical data samples based on real-time uploads from vehicles, building an incremental learning mechanism to continuously optimize the multimodal data fusion decision model. The platform dynamically adjusts the splitting threshold of the lightweight dynamic decision model using various potentially conflicting data. By analyzing the influence weight of each feature in the decision path, it identifies key parameters leading to label conflicts under different driving environments and perception conditions. Through statistical feature extraction of conflicting samples, the platform can accurately capture deficiencies in sensor weight allocation, thereby fine-tuning the decision boundaries of splitting nodes in the decision tree, making the model more adaptable to changing vehicle environments in real-world applications.

[0136] For typical scenarios, the cloud platform identified that when lateral acceleration exceeds 0.25g, the camera's performance is significantly affected by environmental factors such as rain and fog, leading to large deviations in confidence level judgments. Therefore, a new weight adjustment rule was generated, explicitly requiring the vehicle to forcibly reduce the camera's weight by 0.2 under these conditions to improve the accuracy and robustness of the overall fused data. This updated rule is distributed to the vehicle via a secure, encrypted channel and integrated into the dynamic tag generation module, enabling real-time adaptation of the edge computing model. This mechanism not only improves the vehicle's perception reliability in complex dynamic conditions but also drives the intelligent evolution of the smart cockpit system through continuous iteration and rule updates.

[0137] In this embodiment, a multi-source spatiotemporal reference synchronization step utilizes the IEEE 1588 Precision Time Protocol for time synchronization and the ISO 8855 vehicle coordinate system for spatial alignment. This effectively eliminates the spatiotemporal inaccuracy problem of multi-source data, enabling consistency in time and space between different monitoring devices in various complex scenarios. This provides an accurate and reliable data foundation for subsequent data processing and analysis, avoiding erroneous judgments and operations caused by data inaccuracies. Furthermore, the scene label generation and conflict arbitration steps effectively resolve label conflicts by calculating the confidence level of each data source in real time and arbitrating conflicts, improving the accuracy and reliability of scene labels. When encountering contradictory data, it can accurately identify and generate reasonable scene labels, providing a more accurate scene understanding for the intelligent cockpit system, thereby supporting more intelligent and safer decision-making. Furthermore, the service instruction generation and predictive compensation service steps improve the accuracy and stability of data interaction. In complex scenarios, it can accurately match the optimal data source and operation service, generate reasonable service instructions, and predictively compensate for delayed data sources. This ensures stable operation under various conditions, avoiding system failures or operational errors caused by data delays or errors. Based on the identified service commands, cross-domain collaborative execution of these commands is possible, enabling efficient collaborative operation between the smart cockpit and the vehicle's infotainment system, thus improving user experience and driving safety. The infotainment system can update its interface promptly based on real-time and predictive data, providing users with accurate information display and a convenient operating experience. Simultaneously, it automatically triggers related subsystems to execute closed-loop operations, achieving automated and intelligent control of vehicle functions, effectively reducing the user's operational burden and improving driving safety.

[0138] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the vehicle control method described in the above method embodiments.

[0139] The computer program product of the vehicle control method provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the vehicle control method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed methods can also be implemented in other ways. The method embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of 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 marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0141] In addition, the method steps in the various embodiments of this application can be integrated together to form an independent part for execution, or each method step can be executed by a separate module, or two or more steps can be formed into an independent part for execution.

[0142] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0143] The above description is merely a specific embodiment 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 technical scope 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.

Claims

1. A vehicle control method, characterized in that, include: Obtain the initial intent command of the target vehicle; Based on the first state data from the multi-source monitoring equipment of the target vehicle, a spatiotemporally aligned context dataset is formed; wherein, the first state data includes a timestamp, and the context dataset includes multiple pieces of context data; The context dataset is input into the dynamic decision model to obtain multiple initial scene labels; In the case where there are mutually exclusive labels among the initial scene labels, the target scene label is determined based on the confidence level corresponding to each initial scene label; Based on the scene label and the initial intent instruction, a service instruction for the target vehicle is generated; wherein, the service instruction is used to control the target vehicle; The method for determining the confidence level of the initial scene label includes: based on the environment in which the target vehicle is located, performing a first correction on the original confidence level of the source monitoring device of the context data corresponding to the initial scene label to obtain a first corrected confidence level; wherein, the original confidence level is pre-configured for each monitoring device; and performing a second correction on the first corrected confidence level based on the delay duration of the context data to obtain the confidence level of each initial scene label.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the second state data of the target vehicle; The target vehicle is controlled by combining the second status data and the service command.

3. The method according to claim 2, characterized in that, The acquisition of the second state data of the target vehicle includes: Initial state data is obtained based on the multi-source monitoring devices; wherein, the initial state data includes a timestamp; If the time difference between the timestamp and the current time exceeds a delay threshold, a prediction is made based on the initial state data to obtain the predicted current data; wherein, the predicted current data serves as the second state data.

4. The method according to claim 1, characterized in that, The method further includes: According to a set time pattern, the central processing unit of the target vehicle broadcasts a synchronization message to the multi-source monitoring devices; wherein, the synchronization message includes time information; The monitoring device from multiple sources calibrates its local clock based on the time information and the arrival time of the synchronization message.

5. The method according to claim 1, characterized in that, The first state data from the multi-source monitoring device based on the target vehicle forms a spatiotemporally aligned context dataset, including: Acquire the first state data obtained from multi-source monitoring equipment; Spatial alignment is performed on the first state data obtained from each monitoring device to obtain spatially aligned state data. Based on the spatial alignment state data, a spatiotemporal alignment context dataset is formed.

6. The method according to claim 5, characterized in that, The spatial alignment of the first state data obtained from each monitoring device includes: Based on the transformation matrix between the monitoring equipment and the designated location of the target vehicle, the first state data obtained by each monitoring equipment is spatially transformed.

7. A vehicle, characterized in that, Including smart cockpits; The intelligent cockpit includes multi-source monitoring equipment and a central processing unit; The multi-source monitoring equipment is used to detect various status data of the vehicle in question; The central processing unit is configured to combine various state data to execute the steps of the method described in any one of claims 1-6.

Images