A one-to-many remote driving scheduling method and system and a medium

Abstract

The application relates to a one-to-many remote driving scheduling method and system and a medium, the method comprising the following steps of S1: powering on a vehicle end, applying, according to the VIN codes of different vehicles, a vehicle scheduling subsystem to connect a cabin end scheduling port, sending periodic vehicle binding state data to the cabin end scheduling port after successful connection, simultaneously waiting for receiving periodic row binding control instructions fed back by the cabin end, and the uploading chassis state data module, the issuing control vehicle instruction module and the video acquisition uploading module of the vehicle end being in a default state, waiting for a binding signal issued by the cabin end scheduling subsystem to be activated. The application not only forms a wireless connection mode of one driving cabin to multiple scheduling vehicles by directly sending scheduling signals to a remote driving cabin by all vehicles, does not need to build a cloud server platform for communication transfer, has a smaller hardware cost investment, reduces the communication links of data, reduces the control vehicle and video time delay, and processes sudden conditions in time.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to a scheduling method, system and medium for one-to-many remote driving. Background Technology

[0002] With the nation's emphasis on 5G, it has been widely adopted and applied as a new infrastructure. Consequently, the technology industries and application scenarios related to 5G communication are constantly expanding and innovating. 5G remote driving technology, as a solution in intelligent connected autonomous driving, is a crucial means of ensuring the safety of vehicle drivers in particularly dangerous scenarios. For example, in mining scenarios, mining truck operating routes are often in poor condition, with frequent unexpected environmental events, and a high probability of hazards such as falling rocks and landslides. Simple autonomous driving technology alone cannot solve this problem. In such cases, applying 5G remote driving technology allows drivers to utilize their extensive driving experience while ensuring their safety. Furthermore, as a means of autonomous driving, remote driving can be used in conjunction with autonomous driving technology to address the issue of unmanned vehicles malfunctioning when the autonomous driving system fails. It allows for immediate takeover, moving the unmanned vehicle to a maintenance station or resuming its original operation.

[0003] Typical remote driving technology uses a one-to-one connection, meaning one remote cockpit is paired with one vehicle for remote driving. A remote cockpit can only connect to one fixed vehicle for remote driving; to connect to another vehicle, the previous vehicle must be powered off and the connection platform stopped. This remote driving solution has limited functionality. When handling multi-vehicle scheduling, it requires changes to the cockpit configuration to switch vehicles, which is cumbersome and cannot meet the needs of timely scheduling. Another approach uses a server platform to coordinate and bind resources between vehicles and cockpits. However, when dealing with scenarios where multiple vehicles are not simultaneously performing remote driving operations, the communication link is long, real-time performance is poor, and the ability to handle unexpected problems is limited. Summary of the Invention

[0004] In view of the above problems, the present invention provides a one-to-many remote driving scheduling method, system and medium. Not only do all vehicles directly send scheduling signals to the remote cockpit, forming a wireless connection between one cockpit and multiple dispatched vehicles, but there is no need to build a cloud server platform for communication relay, resulting in less hardware cost investment. Furthermore, it reduces data communication links, lowers vehicle control and video latency, and enables timely handling of emergencies.

[0005] To achieve the above and other related objectives, the present invention provides the following technical solution: A method for scheduling one-to-many remote driving includes the following steps: S1: When the vehicle is powered on, the vehicle dispatching subsystem requests to connect to the cabin dispatching port based on the VIN code of different vehicles. After the connection is successful, it sends periodic vehicle binding status data to the cabin dispatching port and waits to receive periodic binding control commands from the cabin. The vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are in the default state, waiting for the cabin dispatching subsystem to issue a binding signal to activate them. S2: Based on the vehicle binding status data sent by the vehicle dispatching subsystem, the cabin-side dispatching subsystem parses the data byte stream according to the original protocol, extracts the vehicle's 17-bit VIN code, the vehicle's authorized cockpit code, the vehicle's current binding status, and the vehicle's current latitude and longitude information, establishes a connection with the corresponding cockpit based on the vehicle's authorized cockpit code, and connects to the cabin-side dispatching port of the corresponding cockpit based on the vehicle's 17-bit VIN code. S3: Based on the connection between the vehicle and the corresponding cockpit, the vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are activated, uploading the vehicle status data to the cockpit, and the cockpit issues a response command to the vehicle-side dispatch subsystem.

[0006] Furthermore, in step S1, if the vehicle dispatching subsystem does not receive a binding control command for an extended period of time, it will proactively close the existing connection and re-apply for a new cabin-end dispatching port connection.

[0007] Furthermore, in step S2, when the vehicle authorized cockpit code is parsed and is different from the current cockpit code, the connection is actively disconnected and the vehicle's reconnection is rejected.

[0008] Furthermore, based on the vehicle's current latitude and longitude information, it is transmitted to the map component in the cabin-side scheduling subsystem, and an icon is created at the corresponding point on the map to mark the vehicle's location.

[0009] Furthermore, the vehicle status data includes vehicle speed, gear, throttle position, brake position, status of each light, and status data of each ECU.

[0010] Furthermore, in step S3, the cockpit issuing a response command to the vehicle-side dispatch subsystem includes the following steps: S31: Based on the vehicle chassis operating status uploaded by the vehicle control command module on the vehicle side, the cockpit sends chassis control commands, which are converted into vehicle-identifiable CAN messages and sent to the specified CAN ID to control the operation of the vehicle chassis. S32: Based on the control of vehicle chassis operation, according to the vehicle image data information uploaded by the video acquisition and uploading module, the cockpit adjusts the vehicle driving trajectory based on the multi-target tracking algorithm and outputs the vehicle driving trajectory information to the vehicle dispatching subsystem. S33: Based on the vehicle driving trajectory information and the chassis status data information uploaded by the chassis status data upload module, the cockpit packages the data into a data packet according to the vehicle control protocol and sends it to the vehicle dispatch subsystem.

[0011] Furthermore, the cockpit performs safety monitoring of network latency, video latency, and physical hardware status, and executes safety measures such as braking and stopping in case of abnormalities.

[0012] To achieve the above and other related objectives, the present invention also provides a one-to-many remote driving dispatching system, the system comprising a cabin-end dispatching system and a vehicle-end dispatching system, the cabin-end dispatching system comprising at least one cabin-end dispatching subsystem for vehicle data transmission and vehicle dispatching, and the vehicle-end dispatching system comprising at least three vehicle dispatching subsystems communicatively connected to the cabin-end dispatching subsystem for vehicle information collection and vehicle control.

[0013] Furthermore, the cabin-end scheduling system also includes a cabin-end interface display system for displaying real-time vehicle status image data and vehicle status data. The vehicle scheduling subsystem includes a chassis status data uploading module, a vehicle control command issuing module, and a video acquisition and uploading module.

[0014] To achieve the above and other related objectives, the present invention also provides a computer-readable storage medium storing a computer program programmed or configured to perform any of the one-to-many remote driving scheduling methods described herein.

[0015] The present invention has the following positive effects: 1. This invention requires only one driver and one cockpit to schedule, bind, and remotely control multiple vehicles. It is suitable for scenarios where remote driving is required for short-term emergency takeover of unmanned vehicles when the autonomous driving system malfunctions.

[0016] 2. In this invention, the remote driving operator waits for remote driving takeover notification at the cockpit. Upon receiving the notification, the operator selects an emergency vehicle on the interface, binds it, and then begins operation. After moving the vehicle to a safe area, the operator continues to wait for the next emergency response. Only one person is needed to remotely drive and dispatch multiple vehicles, minimizing manpower requirements.

[0017] 3. In this invention, all vehicles directly send dispatch signals to the remote cockpit, forming a wireless connection between one cockpit and multiple dispatch vehicles. There is no need to build a cloud server platform for communication relay, resulting in lower hardware costs.

[0018] 4. After the cockpit of this invention is bound to a single vehicle, the vehicle-side control and video modules form a point-to-point direct connection with the cockpit-side software module. The short communication link between vehicle control and video data reduces the number of communication links, lowers the latency of vehicle control and video, and enables timely handling of emergencies. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the cabin-end process of the present invention; Figure 3 This is a schematic diagram of the vehicle-side process of the present invention. Detailed Implementation

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

[0021] Example 1: As Figure 1 As shown, a one-to-many remote driving scheduling method includes the following steps: S1: When the vehicle is powered on, the vehicle dispatching subsystem requests to connect to the cabin dispatching port based on the VIN code of different vehicles. After the connection is successful, it sends periodic vehicle binding status data to the cabin dispatching port and waits to receive periodic binding control commands from the cabin. The vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are in the default state, waiting for the cabin dispatching subsystem to issue a binding signal to activate them. S2: Based on the vehicle binding status data sent by the vehicle dispatching subsystem, the cabin-side dispatching subsystem parses the data byte stream according to the original protocol, extracts the vehicle's 17-bit VIN code, the vehicle's authorized cockpit code, the vehicle's current binding status, and the vehicle's current latitude and longitude information, establishes a connection with the corresponding cockpit based on the vehicle's authorized cockpit code, and connects to the cabin-side dispatching port of the corresponding cockpit based on the vehicle's 17-bit VIN code. S3: Based on the connection between the vehicle and the corresponding cockpit, the vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are activated, uploading the vehicle status data to the cockpit, and the cockpit issues a response command to the vehicle-side dispatch subsystem.

[0022] In step S1, if the vehicle dispatching subsystem does not receive a binding control command for an extended period of time, it will proactively close the existing connection and re-apply for a new cabin-end dispatching port connection.

[0023] In step S2, if the vehicle's authorized cockpit code is parsed and is different from the current cockpit code, the connection is actively disconnected and the vehicle's reconnection is rejected.

[0024] Specifically, based on the vehicle's current latitude and longitude information, it is transmitted to the map component in the cabin-side scheduling subsystem, and an icon is created at the corresponding point on the map to mark the vehicle's location.

[0025] The vehicle status data includes vehicle speed, gear, throttle value, brake value, status of each light, and status data of each ECU.

[0026] In step S3, the cockpit issuing a response command to the vehicle-side dispatch subsystem includes the following steps: S31: Based on the vehicle chassis operating status uploaded by the vehicle control command module on the vehicle side, the cockpit sends chassis control commands, which are converted into vehicle-identifiable CAN messages and sent to the specified CAN ID to control the operation of the vehicle chassis. S32: Based on the control of vehicle chassis operation, according to the vehicle image data information uploaded by the video acquisition and uploading module, the cockpit adjusts the vehicle driving trajectory based on the multi-target tracking algorithm and outputs the vehicle driving trajectory information to the vehicle dispatching subsystem. S33: Based on the vehicle driving trajectory information and the chassis status data information uploaded by the chassis status data upload module, the cockpit packages the data into a data packet according to the vehicle control protocol and sends it to the vehicle dispatch subsystem.

[0027] Specifically, after the remote cockpit software is started, sub-modules such as the cockpit-side dispatch system server, vehicle control system server, and interface data display system are activated, each binding to different ports on the cockpit side, and continuously monitoring the port connection status in the background. For example... Figure 3 As shown, after the vehicle-side system is powered on, the vehicle-side dispatch subsystem actively requests a connection to the cabin-side dispatch port. Upon successful connection, it actively sends periodic vehicle binding status data to this port while simultaneously waiting to receive periodic binding control commands from the cabin. If no binding control command is received for an extended period, the system will proactively close the existing connection and re-apply for a new one. The vehicle-side chassis status data upload system, vehicle control command issuance system, and video acquisition and upload system are in default states, awaiting activation via a binding signal from the dispatch subsystem.

[0028] When the scheduling module receives the cockpit binding signal, it forwards it to other modules. Upon receiving the signal, the other modules actively operate according to their original logic. For example, the vehicle control module starts receiving cockpit control commands, converts them into vehicle-identifiable CAN messages, and sends them to the designated CAN ID to control the vehicle chassis operation; the video acquisition and upload module starts reading video stream data transmitted from the camera and sends it to the cockpit according to the TCP protocol; the chassis data upload module starts reading the fixed signal with the designated ID in the CAN bus according to the target signal, converts it into byte stream data, and sends it to the cockpit.

[0029] Example 2: Based on the one-to-many remote driving scheduling method in Example 1, the present invention will be further described below.

[0030] like Figure 2 As shown, after receiving the vehicle binding status data from the vehicle, the cabin-side scheduling subsystem parses the data byte stream according to the original protocol, extracting the vehicle's 17-bit VIN code (LUAU2AUB3GE383467), the vehicle's authorized cockpit code (MJU_23), the vehicle's current binding status, and the vehicle's current latitude and longitude information. Simultaneously, a new container is created to package the VIN and connection channel number, and this is passed to the interface control to display the currently online vehicle VIN. If the parsed vehicle authorized cockpit code differs from the current cockpit code, the connection is actively disconnected, and reconnection from that IP address is rejected. If the vehicle is already bound but the cabin has not performed a binding operation, an unbinding message is sent to it by default; otherwise, no action is taken. The latitude and longitude information is passed to the map component, and an icon is created at the corresponding point on the map to mark the vehicle's location. When multiple vehicles are powered on and actively connecting simultaneously, a new thread is actively created to process the vehicle binding status data in parallel, placing the VIN codes in the same container and repeating the above operations. If a channel has no vehicle binding data for an extended period, it is assumed that the vehicle has been powered off. The corresponding VIN and channel in the container are then cleared, and the VIN displayed on the interface is also cleared, making it unselectable.

[0031] After receiving the chassis status data from the vehicle, the cabin-side interface display system processes the byte stream data according to the display protocol, extracting and parsing data such as vehicle speed, gear position, throttle position, brake position, light status, and ECU status. Using loaded icons and drawing programs, this data is visualized through numerical values, dials, image switching, progress bars, etc., and finally displayed on the interface. The values ​​change according to the actual vehicle status, displaying the real-time vehicle status. Upon receiving the vehicle control connection, the cabin-side vehicle control system actively collects hardware data from the steering wheel, pedals, buttons, etc., and further transforms this data according to the hardware driver definition. This data is then packaged into data packets according to the vehicle control protocol and sent to the successfully connected vehicle for remote vehicle control data transmission.

[0032] When the operator at the control center actively selects a VIN code for vehicle binding or unbinding on the interface, the dispatch system sends a binding or unbinding signal to the target vehicle in that channel based on the corresponding connection channel number of that VIN in the container. When the vehicle actively powers on or off, the control center adds to or removes from the VIN code list displayed on the interface based on the received dispatch signal. The cockpit monitors network latency, video latency, and physical hardware status for safety, and executes safety measures such as braking and stopping in case of abnormalities.

[0033] To achieve the above and other related objectives, the present invention also provides a one-to-many remote driving dispatching system, the system comprising a cabin-end dispatching system and a vehicle-end dispatching system, the cabin-end dispatching system comprising at least one cabin-end dispatching subsystem for vehicle data transmission and vehicle dispatching, and the vehicle-end dispatching system comprising at least three vehicle dispatching subsystems communicatively connected to the cabin-end dispatching subsystem for vehicle information collection and vehicle control.

[0034] The cabin-end scheduling system also includes a cabin-end interface display system for displaying real-time vehicle status image data and vehicle status data. The vehicle scheduling subsystem includes a chassis status data uploading module, a vehicle control command issuing module, and a video acquisition and uploading module.

[0035] To achieve the above and other related objectives, the present invention also provides a computer-readable storage medium storing a computer program programmed or configured to perform any of the one-to-many remote driving scheduling methods described herein.

[0036] This application also provides a computer-readable storage medium storing a computer program, which, when executed, implements the following... Figure 1 The method for scheduling one-to-many remote driving is illustrated. The computer-readable storage medium may include, but is not limited to, floppy disks, optical disks, CD-ROMs (Read-Only Optical Disk Memory), magneto-optical disks, ROMs (Read-Only Memory), RAMs (Random Access Memory), and EPROMs (Electronic Power Memory). The computer-readable storage medium may be an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, flash memory, or other type of media / machine-readable medium suitable for storing machine-executable instructions. The computer-readable storage medium may be a product not connected to a computer device or a component used in a computer device.

[0037] In summary, this invention not only allows all vehicles to directly send dispatch signals to the remote cockpit, forming a wireless connection between one cockpit and multiple dispatch vehicles without the need to build a cloud server platform for communication relay, thus reducing hardware costs, but also reduces data communication links, lowers vehicle control and video latency, and enables timely handling of emergencies.

[0038] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A scheduling method for one-to-many remote driving, characterized in that, Includes the following steps: S1. Upon powering on the vehicle, the vehicle dispatch subsystem requests a connection to the cabin dispatch port based on the VIN code of each vehicle. After successful connection, it sends periodic vehicle binding status data to the cabin dispatch port and simultaneously waits to receive periodic binding control commands from the cabin. Meanwhile, the vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are in default mode. Recognize the status and wait for the cabin-side scheduling subsystem to send a binding signal for activation; S2. Based on the vehicle binding status data sent by the vehicle dispatching subsystem, the cabin-side dispatching subsystem parses the data byte stream according to the original protocol, extracts the vehicle's 17-bit VIN code, the vehicle's authorized cockpit code, the vehicle's current binding status, and the vehicle's current latitude and longitude information, establishes a connection with the corresponding cockpit based on the vehicle's authorized cockpit code, and connects to the cabin-side dispatching port of the corresponding cockpit based on the vehicle's 17-bit VIN code. S3. Based on the connection between the vehicle and the corresponding cockpit, the vehicle's chassis status data upload module, vehicle control command issuance module, and video acquisition and upload module are activated, uploading vehicle status data to the cockpit, and the cockpit issues a response command to the vehicle's dispatch subsystem; In step S2, when the vehicle authorized cockpit code is parsed and is different from the current cockpit code, the connection is actively disconnected and the vehicle's reconnection is rejected. In step S3, the cockpit issues a response command to the vehicle-side dispatch subsystem, which includes the following steps: S31. Based on the vehicle chassis operating status uploaded by the vehicle control command module at the vehicle end, the driver's cab sends chassis control commands, which are converted into vehicle-identifiable CAN messages and sent to the specified CAN ID to control the operation of the vehicle chassis. S32. Based on the control of vehicle chassis operation, according to the vehicle image data information uploaded by the video acquisition and uploading module, the cockpit adjusts the vehicle driving trajectory based on a multi-target tracking algorithm and outputs the vehicle driving trajectory information to the vehicle dispatching subsystem. S33. Based on the vehicle driving trajectory information and the chassis status data information uploaded by the chassis status data upload module, the cockpit packages the data into a data packet according to the vehicle control protocol and sends it to the vehicle dispatch subsystem.

2. The scheduling method for one-to-many remote driving according to claim 1, characterized in that: In step S1, if the vehicle dispatching subsystem does not receive a binding control command for an extended period of time, it will proactively close the existing connection and re-apply for a new cabin-end dispatching port connection.

3. The scheduling method for one-to-many remote driving according to claim 1, characterized in that: Based on the vehicle's current latitude and longitude information, it is transmitted to the map component in the cabin dispatch subsystem, and an icon is created at the corresponding point on the map to mark the vehicle's location.

4. The scheduling method for one-to-many remote driving according to claim 1, characterized in that: The vehicle status data includes vehicle speed, gear, throttle position, brake position, status of each light, and status data of each ECU.

5. The scheduling method for one-to-many remote driving according to claim 1, characterized in that: The cockpit monitors network latency, video latency, and physical hardware status for safety, and executes safety measures such as braking and stopping in case of abnormalities.

6. A dispatching system for one-to-many remote driving, characterized in that, The system is used to implement the one-to-many remote driving scheduling method according to any one of claims 1-5. The system includes a cabin-end scheduling system and a vehicle-end scheduling system. The cabin-end scheduling system includes at least one cabin-end scheduling subsystem for vehicle data transmission and vehicle scheduling. The vehicle-end scheduling system includes at least three vehicle scheduling subsystems communicatively connected to the cabin-end scheduling subsystem for vehicle information collection and vehicle control. The cabin-end scheduling system also includes a cabin-end interface display system for displaying real-time vehicle status image data and vehicle status data. The vehicle scheduling subsystem includes a chassis status data uploading module, a vehicle control command issuing module, and a video acquisition and uploading module.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is programmed or configured to perform the one-to-many remote driving scheduling method according to any one of claims 1 to 5.

Images