Communication method, system, and vehicle

Abstract

The application discloses a communication method, system and vehicle. The system comprises a robot end, a gateway end and a vehicle end. The method comprises the following steps: establishing a Bluetooth communication connection between the robot end and the gateway end; sending a target control instruction to the gateway end through the Bluetooth communication connection and the robot end, wherein the target control instruction comprises a prefix digital identifier, and the prefix digital identifier is used for determining the vehicle end to be controlled; analyzing the target control instruction through the gateway end, determining the vehicle end and target control data; and sending the target control data to the vehicle end through the gateway end, wherein the vehicle end is used for performing a preset action according to the target control data. The application solves the technical problem of poor stability and low reliability of a communication link in a cross-platform robot vehicle control scene of heterogeneous operating systems.

Description

Technical Field

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

[0002] In the field of interconnecting smart mobile terminals and in-vehicle systems, communication compatibility between heterogeneous operating systems is a key technical challenge. In related technologies, robots and vehicle systems typically communicate directly via native Bluetooth or a local area network. However, these direct connection methods suffer from incompatibility in the underlying Bluetooth encryption handshake mechanisms of heterogeneous systems, internal mechanism conflicts, and the lack or restriction of underlying drivers by closed systems. This results in unstable cross-platform vehicle control links, low reliability, and difficulty in achieving efficient and stable remote real-time control.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a communication method, system, and vehicle to at least solve the technical problems of poor communication link stability and low reliability in cross-platform robot vehicle control scenarios using heterogeneous operating systems.

[0005] According to one aspect of the embodiments of this application, a communication method is provided, applied to a communication system, the communication system including: a robot end, a gateway end, and a vehicle-mounted terminal. The method includes: establishing a Bluetooth communication connection between the robot end and the gateway end; sending a target control command to the gateway end through the Bluetooth communication connection and the robot end, wherein the target control command includes a prefix numeric identifier, the prefix numeric identifier being used to determine the vehicle-mounted terminal to be controlled; parsing the target control command through the gateway end to determine the vehicle-mounted terminal and target control data; and sending the target control data to the vehicle-mounted terminal through the gateway end, wherein the vehicle-mounted terminal is used to execute a preset action according to the target control data.

[0006] Optionally, the communication method further includes: controlling the gateway terminal to send a null command in a preset format to any vehicle terminal based on a preset interval, wherein the null command is used to reset the timer on the vehicle terminal.

[0007] Optionally, establishing a Bluetooth communication connection between the robot and the gateway includes: on the robot side, establishing a low-level Bluetooth connection by calling a preset interface, wherein the timeout of the low-level Bluetooth connection is an empty value; on the gateway side, creating a Bluetooth socket on the low-level Bluetooth connection using a preset reflection mechanism to establish a Bluetooth communication connection, wherein the Bluetooth socket is used for Bluetooth data transmission.

[0008] Optionally, the communication method further includes: triggering a control event via the robot end; generating an initial control command in response to the control event; and generating a target control command by adding a prefix numeric identifier to the beginning of the initial control command.

[0009] Optionally, the vehicle-mounted unit is determined by parsing the target control command at the gateway, including: parsing the prefix numeric identifier in the target control command at the gateway to obtain the network address and network port; and determining the vehicle-mounted unit based on the network address and network port.

[0010] Optionally, the target control data is determined by parsing the target control command at the gateway, including: parsing the target control command at the gateway to obtain initial control data containing a prefix numeric identifier; and separating the prefix numeric identifier from the initial control data to obtain the target control data.

[0011] Optionally, the communication method further includes: in response to the target control command not containing a prefixed numeric identifier, simultaneously sending target control data to multiple vehicle-mounted terminals via a gateway.

[0012] Optionally, the communication method further includes: in response to the failure of Bluetooth communication connection establishment, converting the target control command into a serial port signal; and sending the serial port signal to the physical serial port interface of the vehicle terminal to control the vehicle terminal to perform preset actions.

[0013] According to another aspect of the embodiments of this application, a communication system is also provided, including: a robot end, used to send target control instructions with a prefixed numeric identifier via Bluetooth communication connection, the prefixed numeric identifier being used to determine the vehicle end to be controlled; a gateway end, used to send the target control instructions to the vehicle end; and the vehicle end, used to execute preset actions according to the target control instructions.

[0014] According to another aspect of the embodiments of this application, a communication device is also provided, comprising: a connection module for establishing a Bluetooth communication connection between a robot and a gateway; a first sending module for sending a target control command to the gateway via the Bluetooth communication connection and the robot, wherein the target control command includes a prefix numeric identifier, the prefix numeric identifier being used to determine the vehicle terminal to be controlled; a parsing module for parsing the target control command via the gateway to determine the vehicle terminal and target control data; and a second sending module for sending the target control data to the vehicle terminal via the gateway, wherein the vehicle terminal is used to perform a preset action according to the target control data.

[0015] Optionally, the communication device further includes: a third sending module, used to control the gateway to send a null command of a preset format to any vehicle terminal based on a preset interval, wherein the null command is used to reset the timer of the vehicle terminal.

[0016] Optionally, the connection module is also used to: establish a low-level Bluetooth connection on the robot side by calling a preset interface, wherein the timeout of the low-level Bluetooth connection is an empty value; and on the gateway side, create a Bluetooth socket on the low-level Bluetooth connection using a preset reflection mechanism to establish a Bluetooth communication connection, wherein the Bluetooth socket is used for Bluetooth data transmission.

[0017] Optionally, the communication device further includes: a triggering module for triggering a control event via the robot end; a first generation module for generating an initial control command in response to the control event; and a second generation module for generating a target control command by adding a prefix numeric identifier to the beginning of the initial control command.

[0018] Optionally, the parsing module is also used to: parse the prefix numeric identifier in the target control command through the gateway to obtain the network address and network port; and determine the vehicle-mounted unit based on the network address and network port.

[0019] Optionally, the parsing module is also used to: parse the target control instruction through the gateway to obtain initial control data containing a prefix numeric identifier; and separate the prefix numeric identifier from the initial control data to obtain the target control data.

[0020] Optionally, the communication device further includes: a fourth transmitting module, used to simultaneously transmit target control data to multiple vehicle terminals via the gateway in response to the target control command not containing a prefixed numeric identifier.

[0021] Optionally, the communication device further includes: a conversion module, used to convert the target control command into a serial port signal in response to the failure of Bluetooth communication connection establishment; and a fifth transmission module, used to send the serial port signal to the physical serial port interface of the vehicle terminal to control the vehicle terminal to perform preset actions.

[0022] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the executable program, wherein the executable program performs the methods of various embodiments of this application when running on the processor.

[0023] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0024] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory and the processor is configured to run the computer program to perform the methods in various embodiments of this application.

[0025] In this embodiment, a cross-platform robot control vehicle routing gateway system and communication method based on heterogeneous protocols are adopted. By establishing a Bluetooth communication connection between the robot and the gateway, the robot sends target control commands to the gateway via the Bluetooth communication connection. The target control commands include a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled. Then, the gateway parses the target control commands to determine the vehicle terminal and target control data, and then sends the target control data to the vehicle terminal. The vehicle terminal is used to execute preset actions according to the target control data, achieving the purpose of full-link communication control between the robot, gateway, and vehicle terminal. This achieves the technical effect of high stability and high reliability of cross-platform heterogeneous communication, thereby solving the technical problems of poor communication link stability and low reliability of heterogeneous operating systems in cross-platform robot control vehicle scenarios. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a flowchart of an optional communication method according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of an optional communication method according to an embodiment of this application;

[0029] Figure 3 This is a schematic diagram of an optional communication system according to an embodiment of this application;

[0030] Figure 4 This is a structural block diagram of an optional communication device according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of an optional vehicle according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first", "second" and the like in the specification, claims and accompanying drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific sequence or order. It is to be understood that the data so used may be interchanged where appropriate, so that the embodiments of the present application described herein can be implemented in sequences other than those illustrated or described herein. In addition, the terms "comprising", "having" and any variations thereof are intended to cover non-exclusive inclusion, such that a process, method, system, product or device that comprises a series of steps or units is not necessarily limited to those steps or units expressly listed, but may include other steps or units not expressly listed or inherent to such process, method, product or device.

[0034] With the rapid development of intelligent exhibition halls, unmanned retail and internet of vehicles technologies, the demand for coordinated control between external intelligent devices such as humanoid robots and in-vehicle systems, namely vehicle infotainment systems, is growing increasingly. In an ideal scenario, the robot should be able to send control instructions to the vehicle infotainment system stably and in real time to perform functions such as greeting, navigation assistance or entertainment interaction. However, in actual implementation, the robot end usually runs the Ubuntu / Robot Operating System (ROS) framework, while the vehicle infotainment system end is mostly based on Android or a customized Linux system. The two are typical heterogeneous operating systems with inherent underlying communication barriers.

[0035] Relevant cross-platform communication solutions usually rely on a unified network protocol or a dedicated Application Programming Interface (API) provided by the original manufacturer. However, in practical applications, such direct connection or simple bridging technology has the following main pain points:

[0036] First, poor underlying protocol compatibility leads to unstable connections. When the native classic Bluetooth of the Android system and the Linux system establishes a connection using the Serial Port Profile (SPP) protocol, an unequal encryption handshake mechanism often causes the Android end to throw a socket interception error, such as read ret -1, resulting in frequent disconnection of the communication link or connection failure.

[0037] Secondly, framework-level resource limitations can cause abnormal disconnections. The ROS framework, widely used in robots, sets a default global timeout for sockets (e.g., 60 seconds) during node initialization. If no data exchange occurs after a Bluetooth connection is established, the native socket will trigger a timeout exception and forcibly disconnect, resulting in a "timed self-destruction" disconnection problem that severely impacts control continuity. Sockets are API interfaces provided by the operating system for network communication, encapsulating complex underlying network protocols such as Transmission Control Protocol (TCP) / Internet Protocol (IP) and User Datagram Protocol (UDP). This allows users to establish bidirectional communication channels through simple function calls such as connect(), send(), and recv().

[0038] Secondly, the server-side keep-alive mechanism and firewall blocking communication. Real Android in-vehicle systems typically employ strict heartbeat timeout mechanisms to prevent resource waste, such as kicking out the user if there is no data for 30 seconds. Simultaneously, the underlying iptables firewall of the in-vehicle system blocks external Internet Protocol version 4 (IPv4) port requests by default, preventing external robotic devices from establishing long TCP connections.

[0039] Finally, the hardware expandability of closed systems is limited. Some highly customized Android systems, such as Android 12, for security or size reduction purposes, have removed the basic Linux Bluetooth driver, such as the Bluetooth Universal Serial Bus Driver (btusb), which makes standard external Bluetooth modules unrecognizable or unusable, rendering conventional wireless communication solutions ineffective.

[0040] In summary, the relevant technologies cannot solve problems such as Bluetooth handshake failure, timeout disconnection, firewall blocking, and missing drivers between heterogeneous systems without modifying the underlying code of the vehicle system. This results in poor stability and low reliability of the robot control link, which cannot meet the needs of industrial-grade all-weather control.

[0041] According to an embodiment of this application, a method embodiment of a communication method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0042] Figure 1 This is a flowchart of an optional communication method according to an embodiment of this application, such as... Figure 1 As shown, this method is applied to a communication system, which includes a robot terminal, a gateway terminal, and a vehicle terminal. The method includes:

[0043] Step S11: Establish a Bluetooth communication connection between the robot and the gateway.

[0044] Step S12: Send target control instructions to the gateway via Bluetooth communication connection with the robot. The target control instructions include a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled.

[0045] Step S13: The target control command is parsed through the gateway to determine the vehicle terminal and the target control data;

[0046] Step S14: The target control data is sent to the vehicle terminal through the gateway, whereby the vehicle terminal is used to execute preset actions according to the target control data.

[0047] The aforementioned robot terminal refers to the host computer device running the Robot Operating System (ROS) framework, which is responsible for generating control signals and acting as the communication initiator.

[0048] The aforementioned gateway refers to a smart terminal device running the Android system. As a heterogeneous network bridging gateway, it is responsible for receiving signals from the robot, performing protocol conversion, routing distribution, and maintaining the connection with the vehicle terminal.

[0049] The aforementioned vehicle-mounted terminal refers to the embedded operating system device built into the vehicle, such as the Android / Linux system, which acts as the target execution terminal, responsible for receiving instructions and executing specific control actions.

[0050] The Bluetooth communication connection mentioned above represents a wireless data transmission link established based on the classic Bluetooth SPP protocol, used for low-level communication between the robot and the gateway.

[0051] The aforementioned target control instruction represents a string containing control information generated by the robot, which embeds a specific prefixed numeric identifier used to identify the target device.

[0052] The aforementioned prefix numeric identifier represents a numeric mark appended to the beginning of the target control command, such as "1#", which is used to uniquely identify the specific vehicle terminal instance to be controlled within the local area network, and to identify the identity or group of the target vehicle terminal. It is a key index for realizing multi-point routing distribution.

[0053] The aforementioned target control data represents JavaScript Object Notation (JSON) format data that, after being parsed by the gateway, extracts the pure control content from the prefix numeric identifier. This data is then encapsulated into a standard Type-Length-Value (TLV) binary frame format.

[0054] The aforementioned preset actions refer to the specific in-vehicle function operations performed by the vehicle's infotainment system after receiving and parsing the target control data, such as activating the welcome mode or adjusting the seat.

[0055] This application embodiment first establishes a Bluetooth communication connection between the robot and the gateway. For example, the robot establishes an insecure Bluetooth socket through the native Python Socket interface, bypassing the encrypted handshake restrictions of the Android system, and establishes a stable Bluetooth physical link with the gateway, thereby achieving initial connectivity between heterogeneous systems.

[0056] Secondly, the target control command is sent to the gateway via Bluetooth communication connection between the robot and the terminal. This target control command includes a prefixed numeric identifier, which is used to identify the vehicle-mounted device to be controlled. For example, when generating the control command, the robot dynamically injects a timestamp and concatenates the prefixed numeric identifier. Then, it wirelessly sends the assembled target control command to the gateway via the established Bluetooth communication connection, completing the remote transmission of the control intent.

[0057] For example, after receiving the Bluetooth string instruction at the gateway, it assembles it into a standard TLV binary frame format, which contains a 1-byte type identifier (0x01), a 4-byte data length, and a specific JSON data payload, and sends it to the vehicle's infotainment system via Ethernet.

[0058] Next, the gateway parses the target control commands to determine the vehicle-mounted system and the target control data. For example, the gateway runs an independent heartbeat thread, maintaining a long TCP connection with the vehicle-mounted system by sending empty commands in standard TLV format to prevent the connection from being blocked by the vehicle-mounted system's firewall or timeout mechanism. Simultaneously, the gateway uses regular expressions to extract the prefix numeric identifier from the target control commands, determining the corresponding vehicle-mounted system instance. The target control data, stripped of the identifier, is then encapsulated into a TLV binary frame and precisely pushed to the designated vehicle-mounted system via the Ethernet TCP channel.

[0059] Finally, the target control data is sent to the vehicle's infotainment system via the gateway. The infotainment system executes preset actions according to the target control data. For example, after receiving the TLV binary frame sent by the gateway, the infotainment system parses the protocol, extracts the target control data in JSON format, and drives the onboard hardware or software to execute the corresponding preset actions based on the data content, thus completing the control loop.

[0060] Based on the above steps S11 to S14, this application embodiment adopts a cross-platform robot control vehicle routing gateway system and communication method based on heterogeneous protocols. By establishing a Bluetooth communication connection between the robot and the gateway, the robot sends a target control command to the gateway via the Bluetooth communication connection. The target control command includes a prefix numeric identifier, which is used to identify the vehicle terminal to be controlled. Then, the gateway parses the target control command to determine the vehicle terminal and the target control data. The gateway then sends the target control data to the vehicle terminal, whereby the vehicle terminal executes a preset action according to the target control data. This achieves the goal of full-link communication control between the robot, gateway, and vehicle terminal, thereby realizing the technical effect of high stability and high reliability of cross-platform heterogeneous communication. This solves the technical problem of poor communication link stability and low reliability of heterogeneous operating systems in cross-platform robot control vehicle scenarios.

[0061] Optionally, the communication method further includes: controlling the gateway terminal to send a null command in a preset format to any vehicle terminal based on a preset interval, wherein the null command is used to reset the timer on the vehicle terminal.

[0062] The aforementioned preset interval represents a fixed time period set in the heartbeat thread inside the gateway, such as 15 seconds, used to trigger the action of sending timed commands.

[0063] The above-mentioned preset format is the standard TLV binary frame format, which includes type identifier, data length and optional data values. It is the communication data encapsulation structure agreed upon between the gateway and the vehicle terminal.

[0064] The above empty instruction indicates that the Value part in the TLV format is empty or only contains a specific identifier. It does not carry actual control business data and is used specifically to maintain the connection state.

[0065] The timer mentioned above represents the timeout detection mechanism configured on the vehicle-mounted TCP server, such as a 30-second no-data-heartbeat timeout kick-out mechanism, used to monitor connection activity. If no data is received within the specified time, the connection is determined to be disconnected.

[0066] This application embodiment controls the gateway to send a pre-formatted null command to any vehicle-mounted terminal at a preset interval. The null command is used to reset the timer on the vehicle-mounted terminal. For example, the gateway internally runs an independent heartbeat thread that, at preset time intervals, such as every 15 seconds, proactively sends a null command conforming to a preset format (standard TLV binary frame) to any vehicle-mounted terminal currently maintaining a long TCP connection. This action does not transmit service data; it only serves as an activity signal at the network layer, ensuring that the network connection remains active at the TCP layer.

[0067] Then, upon receiving an empty command from the gateway, the vehicle's infotainment system recognizes it as a valid communication data packet, thereby refreshing or resetting its internally configured timeout timer. This mechanism prevents the infotainment system from triggering the default timeout disconnection logic due to prolonged lack of service data, ensuring the continuous survival of the TCP connection.

[0068] Based on the above optional embodiments, this application embodiment sends a pre-formatted null command to any vehicle terminal at a preset interval, and resets the timer of the vehicle terminal by the null command. This breaks the strict timeout blocking mechanism of the vehicle terminal, realizes the effective keep-alive of TCP long connections, ensures the stable 24 / 7 connection of the communication link between the gateway and the vehicle terminal, avoids abnormal disconnection caused by non-business data transmission, and significantly improves the reliability of the cross-platform robot vehicle control system.

[0069] Optionally, establishing a Bluetooth communication connection between the robot and the gateway includes: on the robot side, establishing a low-level Bluetooth connection by calling a preset interface, wherein the timeout of the low-level Bluetooth connection is an empty value; on the gateway side, creating a Bluetooth socket on the low-level Bluetooth connection using a preset reflection mechanism to establish a Bluetooth communication connection, wherein the Bluetooth socket is used for Bluetooth data transmission.

[0070] The aforementioned preset interfaces represent the function interfaces in Python's native Socket library used to establish Bluetooth connections, such as socket.AF_BLUETOOTH, which are used to directly access the underlying Bluetooth protocol stack on the robot side.

[0071] The aforementioned low-level Bluetooth connection refers to the original Bluetooth physical link established at the operating system kernel or driver layer, which is different from a secure connection encapsulated by an upper-layer protocol stack.

[0072] The timeout period mentioned above represents the maximum waiting time for a socket to receive data or for an operation to complete. If no data is received within this time, the connection is considered to have timed out and an exception is thrown.

[0073] The above null value indicates that the timeout parameter is set to None or an equivalent infinite wait state, meaning that the socket operation has no time limit.

[0074] The aforementioned preset reflection mechanism refers to the technical mechanism in the Android Java layer used to dynamically access and modify class member variables or call non-public methods at runtime, such as the Java Reflection Application Programming Interface (Reflection API), which is used to bypass the system's default security restrictions.

[0075] The Bluetooth socket mentioned above represents a programming interface object used for reading and writing data on a Bluetooth link, realizing the actual transmission and reception of data.

[0076] The Bluetooth data transmission described above refers to the sending and receiving of binary or string data via Bluetooth sockets.

[0077] In this embodiment, when establishing a Bluetooth communication connection between the robot and the gateway, the robot establishes a low-level Bluetooth connection by calling a preset interface, where the timeout value of the low-level Bluetooth connection is null. For example, the robot directly creates a Bluetooth socket using the native Python Socket interface and explicitly sets the timeout parameter of this socket to null, i.e., `set timeout(None)`. This action bypasses the 60-second global timeout limit imposed by the operating system or ROS framework by default, such as `rospy.init_node`, allowing the robot to wait indefinitely for the Bluetooth connection to be established or for data to respond, thus preventing "timed self-destruction" type abnormal disconnection caused by framework-level timeout settings.

[0078] On the gateway side, a Bluetooth socket is created on the underlying Bluetooth connection using a pre-defined reflection mechanism to establish a Bluetooth communication connection. This Bluetooth socket is used for Bluetooth data transmission. For example, the Android gateway dynamically calls a non-public underlying API via Java reflection to force the creation of an insecure socket. This action bypasses the Android system's default Service Discovery Protocol (SDP) interception and encrypted handshake requirements, directly connecting to the physical Bluetooth channel. The created Bluetooth socket is then used for transparent transmission of raw data between the robot and the gateway, resolving socket interception errors (such as `read ret -1`) caused by asymmetric encrypted handshakes between the Android and Linux systems.

[0079] Based on the above optional embodiments, this application embodiment sets the timeout of the underlying Bluetooth connection to a null value on the robot side to be immune to the framework-level timeout limit, and uses a preset reflection mechanism to create an insecure Bluetooth socket on the gateway side to bypass the encrypted handshake interception. This completely solves the connection tearing problem caused by the asymmetry of security policies and timeout mechanisms between Android and Linux heterogeneous systems, realizes stable and seamless disconnection and reconnection of underlying Bluetooth communication, and lays a physical link foundation for reliable data transmission of upper-layer applications.

[0080] Optionally, the communication method further includes: triggering a control event via the robot end; generating an initial control command in response to the control event; and generating a target control command by adding a prefix numeric identifier to the beginning of the initial control command.

[0081] The aforementioned control events represent conditions or signals that trigger the execution of specific business logic or actions within the robot, such as the activation of "welcome mode," completion of path planning, or arrival of user interaction commands.

[0082] The aforementioned initial control command represents the raw data format generated by the robot based on the control event, containing specific control logic and data parameters. It is usually presented as a string containing JSON format data, but does not yet contain identification information for routing and distribution.

[0083] In this embodiment of the application, when generating target control instructions, a control event is first triggered on the robot's end. For example, the robot's host computer program, such as a ROS Python node, detects internal state changes or external inputs, such as a user clicking the screen or sensor data reaching a certain threshold, thereby activating the corresponding control logic flow. This step is the starting point of the control chain, marking the generation of control requirements.

[0084] In response to a control event, an initial control command is generated. For example, the robot extracts or constructs a data object containing specific control parameters based on the triggered control event and serializes it into a standard JSON string. At this point, the initial control command only contains business logic content, such as function names and parameter values, and does not contain any network routing-related metadata.

[0085] After generating the initial control command, a target control command is generated by adding a prefix numeric identifier to the beginning of the initial control command. For example, the robot dynamically appends a specific numeric identifier, such as "1#", to the leftmost side of the generated initial control command string to generate the final target control command. This action transforms the original command without routing information into a target control command with a clear target indication, enabling the subsequent gateway to identify the target vehicle terminal based on this prefix.

[0086] Based on the above optional embodiments, this application embodiment triggers a control event from the robot end, generates an initial control command in response to the control event, and adds a prefix numeric identifier to the front end of the initial control command to generate a target control command. This realizes the structured combination of control business data and routing identification information, providing a data foundation for the gateway end to extract digital routes based on the command string prefix. This enables a single gateway device to accurately identify the target vehicle terminal based on the prefix, thereby supporting the parallel distribution of control flows to multiple target vehicle terminals or the execution of mass broadcasts, improving the flexibility and accuracy of control command distribution.

[0087] Optionally, the vehicle-mounted unit is determined by parsing the target control command at the gateway, including: parsing the prefix numeric identifier in the target control command at the gateway to obtain the network address and network port; and determining the vehicle-mounted unit based on the network address and network port.

[0088] The aforementioned network address represents logical addressing information used to identify a specific device in the network. In this embodiment of the application, it may include an IPv4 address or an IPv6 address, used to locate the physical or logical network location of the target vehicle terminal.

[0089] The aforementioned network ports represent numerical identifiers in the TCP / IP protocol stack used to distinguish different network services on the same device, such as ports 8800 to 8805, which are used to direct data streams to specific TCP server programs on the vehicle's infotainment system.

[0090] In this embodiment, when the gateway parses the target control command to determine the vehicle-mounted terminal, it obtains the network address and network port by parsing the prefix numeric identifier in the target control command. For example, after receiving the target control command from the robot, the gateway uses regular expressions or other string processing techniques to extract the prefix numeric identifier at the very beginning of the command string. The gateway internally maintains a mapping table between the prefix numeric identifier and the network address and network port. By looking up the table or performing calculations, the extracted prefix numeric identifier is converted into the corresponding network address and network port of the target vehicle-mounted terminal. This action realizes the conversion from logical command identification to physical network addressing.

[0091] The vehicle-mounted device is then determined based on the network address and port. For example, the gateway uses the resolved network address and port to match against a pool of established TCP client instances within the local area network. The gateway checks if a TCP connection instance already connected to that specific network address and port exists. If it does, the instance is identified as the corresponding vehicle-mounted device. If it does not exist, a connection establishment process may be triggered. This step clarifies the specific target entity for the instruction delivery.

[0092] Based on the above optional embodiments, this application embodiment obtains the network address and network port by parsing the prefix numeric identifier in the target control command at the gateway end, and determines the vehicle terminal based on the network address and network port, realizing dynamic routing distribution based on the command prefix. This enables the gateway end to accurately identify the target vehicle terminal based on the prefix and deliver the control command to the corresponding TCP connection instance, thereby supporting the parallel issuance of control flows to multiple target vehicle terminals or the execution of mass broadcasts, improving the flexibility and accuracy of control command distribution, and avoiding command conflicts or mis-sending in multi-device scenarios.

[0093] Optionally, the target control data is determined by parsing the target control command at the gateway, including: parsing the target control command at the gateway to obtain initial control data containing a prefix numeric identifier; and separating the prefix numeric identifier from the initial control data to obtain the target control data.

[0094] The aforementioned initial control data represents the original, complete instruction string received by the gateway from the Bluetooth channel, which has not undergone any content processing or stripping. It retains the prefix numeric identifier generated by the robot and the subsequent JSON business data.

[0095] In this embodiment of the application, when parsing the target control command to determine the target control data at the gateway, the gateway parses the target control command to obtain initial control data containing a prefix numeric identifier. For example, after receiving the target control command string sent by the robot, the gateway parses it as input data. At this time, the data structure obtained by the gateway remains in its original state, that is, the prefix numeric identifier is closely linked to the subsequent JSON business data, constituting complete initial control data.

[0096] The target control data is obtained by separating the prefix numeric identifier from the initial control data. For example, the gateway uses regular expressions or string manipulation techniques to identify and remove the prefix numeric identifier from the beginning of the initial control data. After separation, the remaining part is clean JSON data without routing identifiers, i.e., the target control data. This process decouples control business data from routing metadata, ensuring that the data sent to the vehicle's infotainment system conforms to the system's expected parsing format.

[0097] Based on the above optional embodiments, this application embodiment obtains initial control data containing a prefix numeric identifier by parsing the target control command at the gateway end, and separates the prefix numeric identifier from the initial control data to obtain the target control data. This decouples the routing information and business data in the control command, ensures that the target control data sent to the vehicle terminal is in a clean standard format, avoids parsing anomalies caused by the vehicle terminal parsing a prefix identifier of an unexpected format, and improves the accuracy and compatibility of data processing.

[0098] Optionally, the communication method further includes: in response to the target control command not containing a prefixed numeric identifier, simultaneously sending target control data to multiple vehicle-mounted terminals via a gateway.

[0099] In this embodiment of the application, in response to the target control command not containing a prefix numeric identifier, target control data is simultaneously sent to multiple vehicle-mounted terminals via a gateway. For example, when parsing the target control command, the gateway checks whether a specific prefix numeric identifier exists in the command string. If it does not exist, this status indicates that the command issued by the robot is a global broadcast command or a group command, rather than a targeted command for a specific single vehicle-mounted terminal.

[0100] After determining that the target control command does not contain a prefix numeric identifier, the gateway iterates through its internally maintained TCP long-lived connection instances established with multiple vehicle-mounted terminals. The gateway then copies the target control data (after removing the prefix) in parallel and sends it to all online vehicle-mounted terminals through all active TCP connection instances. This process achieves network-wide broadcast distribution of the control command.

[0101] Based on the above optional embodiments, this application embodiment, in response to the target control command not containing a prefix numeric identifier, simultaneously sends target control data to multiple vehicle terminals through the gateway, realizing the global broadcast function for control commands without specific target identifiers. This enables a single gateway device to simultaneously send the same control flow to all online vehicle terminals in the local area network, meeting the application requirements of multi-vehicle collaborative control or full-scenario broadcast notification, improving the coverage and efficiency of command issuance, and achieving the group sending effect without configuring target addresses one by one.

[0102] Optionally, the communication method further includes: in response to the failure of Bluetooth communication connection establishment, converting the target control command into a serial port signal; and sending the serial port signal to the physical serial port interface of the vehicle terminal to control the vehicle terminal to perform preset actions.

[0103] The above Bluetooth communication connection establishment failure indicates that when the gateway and the robot attempt to establish a wireless data link based on the classic Bluetooth SPP protocol or TCP / IP network, the connection request cannot be successfully responded to or the connection is immediately disconnected due to reasons such as unequal encryption handshake, timeout interruption, firewall blocking or missing driver, resulting in the inability to use the normal wireless data transmission channel.

[0104] The serial port signals mentioned above represent serial data signals encoded and transmitted according to the Universal Asynchronous Receiver / Transmitter (UART) electrical standard. They are typically represented by a sequence of voltage level changes transmitted through physical pins, such as the Transmit Data (TXD) signal pin and the Receive Data (RXD) signal pin. These signals include start bits, data bits, stop bits, and parity bits. They are compatible with standard USB to Transistor-Transistor Logic (TTL) or Recommended Standard 232 (RS232) interface protocols.

[0105] The aforementioned physical serial port interface refers to the hardware connection port reserved on the vehicle's built-in embedded operating system device, i.e., the vehicle's infotainment system, for serial communication. This could be a USB Type-B interface, a Mini Universal Serial Bus (Mini-USB) interface, or a pin header interface, which supports direct connection to external serial communication devices via physical cables.

[0106] In response to a Bluetooth communication connection failure, this embodiment converts the target control command into a serial port signal. For example, when the gateway detects a Bluetooth communication connection failure with the robot and is unable to transmit data wirelessly, a backup communication mechanism is triggered. The gateway extracts the control logic content from the target control command, converts it into a serial data frame conforming to the UART communication protocol, and generates the corresponding physical level signal using a built-in or external USB-to-TTL chip, such as the CH340 chip. This process achieves the conversion from logic commands to physical serial signals, bypassing the dependency on wireless drivers and the Bluetooth protocol stack.

[0107] The serial port signal is sent to the physical serial port interface of the vehicle's infotainment system to control the system to execute preset actions. For example, the gateway connects the generated serial port signal to the physical serial port interface of the vehicle's infotainment system via a USB cable or dedicated data cable. The vehicle's infotainment system listens to the serial data received through this physical interface, parses the control command, and maps it to the corresponding preset action execution module. This action establishes a wired physical transparent transmission channel from the gateway to the vehicle's infotainment system, ensuring that control commands can still be sent even when the wireless link is unavailable.

[0108] Based on the above optional embodiments, this application embodiment, in response to Bluetooth communication connection establishment failure, converts the target control command into a serial port signal and sends the serial port signal to the physical serial port interface of the vehicle terminal to control the vehicle terminal to execute preset actions. This provides a highly reliable hardware fallback communication solution, effectively solving the communication interruption problem caused by the lack of basic Bluetooth drivers in the closed system or wireless environment interference leading to connection unavailability. It achieves bypassing wireless driver limitations through an external USB to TTL physical pass-through architecture, ensuring that all vehicle terminal control commands can be delivered in extreme or special hardware environments, significantly improving the system's fault tolerance and all-weather operational stability.

[0109] Figure 2 This is a schematic diagram of an optional communication method according to an embodiment of this application, such as... Figure 2 As shown in the figure, this diagram illustrates the firewall traversal strategy when the gateway sends Ethernet control flow to the vehicle's infotainment system. Specifically, when the gateway sends control data to the target vehicle's IPv4 port 8800, the system first determines whether the IPv4 port is blocked by the underlying iptables firewall. If the result is that it is not blocked, a normal IPv4 TCP port connection is established, and the vehicle's infotainment system successfully receives and executes the command. If the result is that it is blocked, a dynamic switching mechanism is triggered. The gateway dynamically switches and binds to the target vehicle's IPv6 address, using the IPv6 network to bypass the security restrictions at the IPv4 layer, thereby establishing a connection and ultimately ensuring that the vehicle's infotainment system successfully receives and executes the command. This process demonstrates the technical means by which the embodiments of this application overcome the blocking of closed system firewalls through the IPv4 / IPv6 dual-stack dynamic switching mechanism.

[0110] According to another aspect of the embodiments of this application, a communication system is also provided, including: a robot end, used to send target control instructions with a prefixed numeric identifier via Bluetooth communication connection, the prefixed numeric identifier being used to determine the vehicle end to be controlled; a gateway end, used to send the target control instructions to the vehicle end; and the vehicle end, used to execute preset actions according to the target control instructions.

[0111] The aforementioned communication system includes a robot-side terminal, a gateway-side terminal, and a vehicle-mounted terminal. Specifically, when generating control commands, the ROS node on the robot-side uses software logic to concatenate specific numeric characters, such as "1#", to the beginning of the command string, forming a complete target control command with routing information. This command is then wirelessly transmitted to the gateway-side terminal via an established Bluetooth communication connection.

[0112] After receiving the target control command sent by the robot, the gateway parses the prefix numeric identifier to determine the network address or TCP connection instance of the target vehicle terminal, and forwards the parsed command data to the designated vehicle terminal through the local area network TCP connection or physical serial port pass-through channel.

[0113] After receiving the target control command sent by the gateway, the vehicle's infotainment system parses the command content in a specific format, such as TLV decoding or JSON parsing, extracts the control parameters, and calls the underlying driver or system service to execute the corresponding preset actions, thereby completing the control of the vehicle's functions.

[0114] Based on the above optional embodiments, this application embodiment sends target control commands with prefixed numeric identifiers through the robot end, the gateway end sends the target control commands to the vehicle end, and the vehicle end executes preset actions according to the target control commands. This realizes a full-link closed-loop control in a heterogeneous system environment, which establishes an initial connection and routes commands using Bluetooth communication, and finally the vehicle end accurately executes the control tasks. This ensures that commands can accurately point to the target vehicle and be effectively executed in multi-device scenarios, improving the accuracy of cross-platform communication and the reliability of control execution.

[0115] Figure 3 This is a schematic diagram of an optional communication system according to an embodiment of this application, such as... Figure 3 As shown, the system mainly consists of three parts: the robot end, the gateway end, and the vehicle-mounted terminal. On the robot end, ROS topics are used to publish and control command data. The bridging node is responsible for intercepting messages in the ROS topics, extracting the target control commands, injecting a prefixed numeric identifier, and then sending the commands to the gateway end via the Bluetooth communication module. The gateway end, as the core hub, contains a preset reflection mechanism and a long-connection client pool. The preset reflection mechanism establishes an insecure socket through Java's underlying reflection mechanism, achieving a stable Bluetooth connection with the robot end and immunity to ROS framework timeout limitations. The long-connection client pool maintains long TCP connections with multiple vehicle-mounted terminals. After receiving a target control command with a prefixed numeric identifier, the gateway end selects the corresponding TCP connection instance from the long-connection client pool by parsing the identifier, converts the command into TLV format, and sends it to the corresponding target vehicle-mounted terminal. Figure 3 The document specifically demonstrates that the gateway can simultaneously connect to multiple vehicle-mounted systems, including vehicle-mounted system 1, vehicle-mounted system 2, and vehicle-mounted system 3, enabling precise routing and distribution of commands and forming a complete control link from command generation at the robot end to execution at the vehicle-mounted system end.

[0116] For example, this application embodiment uses the "Welcome Mode" as an example to describe in detail the full-link control closed-loop implementation process of a cross-platform robot vehicle control routing gateway system based on heterogeneous protocols. First, the robot triggers the "Welcome Mode" event. The ROS Python node intercepts the update message of the internal topic / pad_car_command, extracts the JSON data and dynamically injects the current timestamp, then assembles the target control command string with the prefix "1#", and sends an empty string to reset the current ROS topic state to complete the "read-once-destroy" operation.

[0117] Next, the target control command is wirelessly transmitted to the Android gateway via the timeout-free AF_BLUETOOTH channel. The gateway recognizes the "1#" prefix and converts the subsequent JSON data into a TLV binary array containing the type identifier "0x01", a 4-byte big-endian length identifier, and the original JSON payload.

[0118] Finally, the gateway uses the maintained TCP long connection, which is protected by a 15-second TLV heartbeat protection mechanism, to push TLV format data to the target vehicle terminal 1. The vehicle terminal parses the TLV format data and executes the corresponding preset control actions, thereby completing the closed-loop control of the entire link from robot terminal instruction generation to vehicle terminal action execution.

[0119] Figure 4 This is a structural block diagram of an optional communication device according to an embodiment of this application, such as... Figure 4 As shown. The device includes:

[0120] The connection module 401 is used to establish a Bluetooth communication connection between the robot and the gateway; the first sending module 402 is used to send a target control command to the gateway via the Bluetooth communication connection with the robot, wherein the target control command includes a prefix numeric identifier, which is used to identify the vehicle terminal to be controlled; the parsing module 403 is used to parse the target control command through the gateway to determine the vehicle terminal and the target control data; the second sending module 404 is used to send the target control data to the vehicle terminal through the gateway, wherein the vehicle terminal is used to execute a preset action according to the target control data.

[0121] Optionally, the communication device further includes: a third sending module 405, used to control the gateway to send a null command of a preset format to any vehicle terminal based on a preset interval, wherein the null command is used to reset the timer of the vehicle terminal.

[0122] Optionally, the connection module 401 is further configured to: establish a low-level Bluetooth connection on the robot side by calling a preset interface, wherein the timeout of the low-level Bluetooth connection is an empty value; and on the gateway side, create a Bluetooth socket on the low-level Bluetooth connection using a preset reflection mechanism to establish a Bluetooth communication connection, wherein the Bluetooth socket is used for Bluetooth data transmission.

[0123] Optionally, the communication device further includes: a triggering module 406 for triggering a control event via the robot end; a first generation module 407 for generating an initial control command in response to the control event; and a second generation module 408 for generating a target control command by adding a prefix numeric identifier to the beginning of the initial control command.

[0124] Optionally, the parsing module 403 is also used to: parse the prefix numeric identifier in the target control command through the gateway to obtain the network address and network port; and determine the vehicle terminal based on the network address and network port.

[0125] Optionally, the parsing module 403 is further configured to: parse the target control instruction through the gateway to obtain initial control data containing a prefix numeric identifier; and separate the prefix numeric identifier from the initial control data to obtain the target control data.

[0126] Optionally, the communication device further includes: a fourth transmitting module 409, used to simultaneously transmit target control data to multiple vehicle terminals via a gateway in response to the target control command not containing a prefixed numeric identifier.

[0127] Optionally, the communication device further includes: a conversion module 410, used to convert the target control command into a serial port signal in response to the failure of Bluetooth communication connection establishment; and a fifth transmission module 411, used to send the serial port signal to the physical serial port interface of the vehicle terminal to control the vehicle terminal to perform preset actions.

[0128] Figure 5 This is a schematic diagram of an optional vehicle according to an embodiment of this application, such as... Figure 5 As shown. The vehicle includes: a memory 501 storing an executable program; and a processor 502 for running the executable program, wherein the executable program, when run on the processor, performs the methods of various embodiments of this application:

[0129] Establish a Bluetooth communication connection between the robot and the gateway; send target control commands to the gateway via the Bluetooth communication connection between the robot and the gateway, wherein the target control commands include a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled; parse the target control commands through the gateway to determine the vehicle terminal and target control data; send the target control data to the vehicle terminal through the gateway, wherein the vehicle terminal is used to execute preset actions according to the target control data.

[0130] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of the various embodiments of this application:

[0131] Establish a Bluetooth communication connection between the robot and the gateway; send target control commands to the gateway via the Bluetooth communication connection between the robot and the gateway, wherein the target control commands include a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled; parse the target control commands through the gateway to determine the vehicle terminal and target control data; send the target control data to the vehicle terminal through the gateway, wherein the vehicle terminal is used to execute preset actions according to the target control data.

[0132] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the methods in various embodiments of this application:

[0133] Establish a Bluetooth communication connection between the robot and the gateway; send target control commands to the gateway via the Bluetooth communication connection between the robot and the gateway, wherein the target control commands include a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled; parse the target control commands through the gateway to determine the vehicle terminal and target control data; send the target control data to the vehicle terminal through the gateway, wherein the vehicle terminal is used to execute preset actions according to the target control data.

[0134] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0135] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0137] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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 all or 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, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0140] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A communication method applied to a communication system, the communication system comprising: The robot terminal, gateway terminal, and vehicle terminal are characterized by including: Establish a Bluetooth communication connection between the robot and the gateway. Through the Bluetooth communication connection and the robot terminal, a target control command is sent to the gateway terminal, wherein the target control command includes a prefixed numeric identifier, which is used to identify the vehicle terminal to be controlled; The gateway parses the target control command to determine the vehicle-mounted system and the target control data. The target control data is sent to the vehicle terminal through the gateway, wherein the vehicle terminal is used to execute a preset action according to the target control data.

2. The method according to claim 1, characterized in that, The method further includes: Based on a preset interval, the gateway sends a null instruction of a preset format to any of the vehicle-mounted terminals, wherein the null instruction is used to reset the timer of the vehicle-mounted terminal.

3. The method according to claim 1, characterized in that, Establishing a Bluetooth communication connection between the robot and the gateway includes: On the robot side, a low-level Bluetooth connection is established by calling a preset interface, wherein the timeout of the low-level Bluetooth connection is an empty value; At the gateway, a Bluetooth socket is created on the underlying Bluetooth connection using a preset reflection mechanism to establish the Bluetooth communication connection, wherein the Bluetooth socket is used for Bluetooth data transmission.

4. The method according to claim 1, characterized in that, The method further includes: Control events are triggered via the robot terminal; In response to the control event, an initial control command is generated; The target control command is generated by adding the prefix numeric identifier to the beginning of the initial control command.

5. The method according to claim 1, characterized in that, The gateway parses the target control command to determine the vehicle-mounted system, including: The gateway parses the prefix numeric identifier in the target control command to obtain the network address and network port; The vehicle-mounted terminal is determined based on the network address and the network port.

6. The method according to claim 1, characterized in that, The gateway parses the target control command to determine the target control data, including: The gateway parses the target control command to obtain initial control data containing the prefix numeric identifier; The target control data is obtained by separating the prefix numeric identifier from the initial control data.

7. The method according to claim 1, characterized in that, The method further includes: In response to the fact that the target control command does not contain the prefix numeric identifier, the target control data is simultaneously sent to multiple vehicle-mounted terminals through the gateway.

8. The method according to claim 1, characterized in that, The method further includes: In response to the failure to establish the Bluetooth communication connection, the target control command is converted into a serial port signal; The serial port signal is sent to the physical serial port interface of the vehicle-mounted system to control the vehicle-mounted system to perform the preset action.

9. A communication system, characterized in that, include: The robot end is used to send target control commands with a prefixed numeric identifier via Bluetooth communication connection. The prefixed numeric identifier is used to identify the vehicle end to be controlled. The gateway is used to send the target control command to the vehicle-mounted system. The vehicle-mounted terminal is used to execute preset actions according to the target control command.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the executable program, wherein the executable program, when running on the processor, performs the communication method as described in any one of claims 1 to 8.

Images