Vehicle interaction method and device in vehicle fleet and storage medium

Abstract

This application provides a vehicle interaction method, device, and storage medium within a vehicle fleet. The communication links between different vehicles within the fleet include a data link and a voice link, with the voice link physically isolated from the data link. The method includes: in response to receiving a first data packet from a first vehicle via the data link, parsing the first data packet; if it is identified that the first vehicle belongs to the fleet and its location data is parsed from the first data packet, rendering the location point of the first vehicle on a pre-loaded area map of the vehicle based on the first vehicle's location data; in response to receiving a second data packet from a second vehicle via the voice link, parsing the second data packet; if it is identified that the second vehicle belongs to the fleet and its voice data is parsed from the second data packet, playing the second vehicle's voice data through the vehicle's voice playback component.

Description

Technical Field

[0001] This application relates to the field of wireless communication, and more specifically, to a vehicle interaction method, device, and storage medium within a vehicle fleet. Background Technology

[0002] Current fleet coordination systems generally rely on cellular mobile communication networks for location data upload, video streaming, and voice communication, and their operation depends on ground base station coverage. When vehicles enter areas without cellular signals, such as canyons, dense forests, plateaus, or polar regions, all network-dependent functional modules of the system lose communication capabilities, resulting in interruption of real-time location sharing, failure of video assistance, and loss of voice communication. This leads to a loss of collaborative operation capabilities, making it impossible to meet the needs of vehicle interaction within the fleet, and resulting in poor interaction stability.

[0003] This demonstrates that the vehicle interaction methods within a fleet in the relevant technologies suffer from poor stability. Summary of the Invention

[0004] This application provides a vehicle interaction method, device, and storage medium within a fleet, to at least address the problem of poor stability in vehicle interaction methods within fleets in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle interaction method within a fleet is provided, wherein the communication link between different vehicles in the fleet includes a data link and a voice link, the data link being a link for transmitting location data, and the communication link being a link for transmitting voice data, the voice link being physically isolated from the data link; the method includes: in response to receiving a first data packet from a first vehicle via the data link, parsing the first data packet; if it is identified that the first vehicle belongs to the fleet and the location data of the first vehicle is parsed from the first data packet, rendering the location point of the first vehicle on a pre-loaded area map of the vehicle based on the location data of the first vehicle; in response to receiving a second data packet from a second vehicle via the voice link, parsing the second data packet; if it is identified that the second vehicle belongs to the fleet and the voice data of the second vehicle is parsed from the second data packet, playing the voice data of the second vehicle through a voice playback component of the vehicle.

[0006] According to another aspect of the embodiments of this application, a vehicle interaction device within a fleet is also provided. The communication link between different vehicles in the fleet includes a data link and a voice link. The data link is a link for transmitting location data, and the communication link is a link for transmitting voice data. The voice link is physically isolated from the data link. The vehicle interaction device includes: a processing unit, configured to parse the first data packet received from the data link from a first vehicle; and to parse the second data packet received from the voice link from a second vehicle; a display unit, configured to display a preloaded area map; and to render the location point of the first vehicle on the area map when it is identified that the first vehicle belongs to the fleet and the location data of the first vehicle is parsed from the first data packet, wherein the location point of the first vehicle is rendered based on the location data of the first vehicle; and a voice playback unit, configured to play the voice data of the second vehicle when it is identified that the second vehicle belongs to the fleet and the voice data of the second vehicle is parsed from the second data packet.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0008] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0009] 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 perform the steps of any of the above method embodiments through the computer program.

[0010] This application addresses the following: Upon receiving a first data packet from a first vehicle via a data link, the first data packet is parsed. If the first vehicle is identified as belonging to a convoy and its location data is parsed from the first data packet, the location point of the first vehicle is rendered on a pre-loaded area map based on the location data. Similarly, upon receiving a second data packet from a second vehicle via a voice link, the second data packet is parsed. If the second vehicle is identified as belonging to a convoy and its voice data is parsed from the second data packet, the voice data of the second vehicle is played through the vehicle's voice playback component. The communication links between different vehicles within the convoy include a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link and data link are physically isolated. Because the communication links between different vehicles within the convoy include a data link and a voice link, and the voice link and data link are physically isolated, location data and voice data can be acquired through separate links, reducing transmission interference between different types of data. Therefore, this solves the problem of poor stability in vehicle interaction methods within convoys in related technologies, thereby improving the stability of vehicle interaction. Attached Figure Description

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of a vehicle interaction method within a fleet according to an embodiment of this application;

[0012] Figure 2 This is a flowchart illustrating an optional vehicle interaction method within a fleet according to an embodiment of this application;

[0013] Figure 3 This is a schematic diagram of an optional vehicle interaction method within a fleet according to an embodiment of this application;

[0014] Figure 4 This is a flowchart illustrating another optional vehicle interaction method within a fleet according to an embodiment of this application;

[0015] Figure 5 This is a structural block diagram of an optional vehicle interaction device within a fleet according to an embodiment of this application;

[0016] Figure 6 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0017] 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.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to one aspect of the embodiments of this application, a vehicle interaction method within a fleet is provided. Optionally, in this embodiment, the above-described vehicle interaction method within a fleet may be applied, but is not limited to, to applications such as... Figure 1 In the hardware environment of the convoy shown, the convoy may include multiple vehicles, each of which can communicate wirelessly with other vehicles 102.

[0020] The vehicle interaction method within a fleet according to the embodiments of this application can be executed by each vehicle 102. Alternatively, the vehicle interaction method within a fleet according to the embodiments of this application can be executed by a client or terminal installed on it.

[0021] Taking vehicle 102 as an example to execute the vehicle interaction method within the fleet in this embodiment, Figure 2 This is a flowchart illustrating an optional vehicle interaction method within a convoy according to an embodiment of this application. The communication links between different vehicles within the convoy include a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link and the data link are physically isolated, such as... Figure 2 As shown, the process of this method may include the following steps:

[0022] Step S202: In response to receiving the first data packet from the first vehicle from the data link, the first data packet is parsed;

[0023] Step S204: If it is determined that the first vehicle belongs to the fleet and the location data of the first vehicle is parsed from the first data packet, the location point of the first vehicle is rendered on the pre-loaded area map of the vehicle based on the location data of the first vehicle.

[0024] Step S206: In response to receiving the second data packet from the second vehicle via the voice link, the second data packet is parsed;

[0025] Step S208: If it is determined that the second vehicle belongs to the fleet and the voice data of the second vehicle is parsed from the second data packet, the voice data of the second vehicle is played through the voice playback component of this vehicle.

[0026] The vehicle interaction method within a fleet in this embodiment can be applied to the field of wireless communication, specifically to scenarios where vehicle interaction occurs in areas without cellular networks.

[0027] Traditional all-terrain vehicle convoy collaboration systems generally rely on cellular mobile communication networks to upload positioning data, transmit video streams, and conduct voice communication. Their operation is based on the premise of ground base station coverage. When vehicles enter areas without cellular signals, such as canyons, dense forests, plateaus, or polar regions, the functional modules that rely on the network will lose their communication capabilities, resulting in the interruption of real-time location sharing, failure of video assistance, loss of voice communication, and loss of collaborative operation capabilities. They have significant functional limitations and reliability defects in wilderness exploration or areas without cellular network coverage.

[0028] Regarding location sharing, while some solutions employ low-power wide-area wireless technologies such as LoRa, their communication protocols are designed for low-frequency, low-data-volume IoT scenarios. Data frame transmission cycles are typically in the hundreds of milliseconds to several seconds, failing to meet the real-time location update requirements of convoy collaboration. Furthermore, in network-free environments, these solutions still rely on central nodes or gateways for data relay and aggregation, resulting in significant latency in location data synchronization within multi-vehicle platoons, making it difficult to support dynamic platooning and path coordination.

[0029] In terms of visual assistance functions, there is currently a lack of real-time, ultra-low latency video transmission capabilities, making it impossible to share the leader's or teammates' field of vision in real time. This results in the leader's field of vision not being effectively transmitted to the vehicles behind, and the inability to make collaborative predictions of complex terrain, obstacles, slopes and potential dangers, significantly increasing the risk of convoy travel.

[0030] At the communication architecture level, when the link performance degrades due to electromagnetic interference, multipath fading, physical obstruction, or hardware failure, the vehicle's business functions will degrade accordingly, potentially leading to coordination chaos and safety incidents.

[0031] This demonstrates that the vehicle interaction methods within a fleet in the relevant technologies suffer from poor stability.

[0032] To at least partially solve the aforementioned technical problems, in this embodiment, in response to receiving a first data packet from a first vehicle via a data link, the first data packet is parsed; if it is identified that the first vehicle belongs to a convoy and its location data is parsed from the first data packet, the location point of the first vehicle is rendered on a pre-loaded area map of the vehicle based on the location data of the first vehicle; in response to receiving a second data packet from a second vehicle via a voice link, the second data packet is parsed; if it is identified that the second vehicle belongs to a convoy and its voice data is parsed from the second data packet, the voice data of the second vehicle is played through the voice playback component of the vehicle. The communication links between different vehicles in the convoy include a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link and the data link are physically isolated. Since the communication links between different vehicles in the convoy include a data link and a voice link, and the voice link and the data link are physically isolated, location data and voice data can be acquired through a separate link, reducing transmission interference between different types of data. Therefore, the problem of poor stability in vehicle interaction methods within a convoy in related technologies can be solved, thereby improving the stability of vehicle interaction.

[0033] Alternatively, the communication links between different vehicles within a fleet can consist of independent data links and voice links.

[0034] Optionally, the data link can adopt the ExpressLRS (ELRS) protocol to build a point-to-multipoint (P2MP) wireless broadcast network based on the Industrial, Scientific and Medical (ISM) band for transmitting real-time vehicle location data and status information.

[0035] Optionally, the voice link uses a separate digital intercom module that can operate on a completely different frequency band than the data link. It can use time division multiple access (TDMA) or frequency division multiple access (FDMA) protocols optimized for voice communication and support full-duplex or half-duplex real-time voice transmission.

[0036] Optionally, the data link and voice link can be deployed using independent hardware boards, with no signal coupling or clock synchronization dependency between them. Their antenna systems can also be configured separately to avoid frequency band interference and antenna mutual coupling. In the communication protocol stack, the data link can use the CRSF frame format to carry telemetry data, while the voice link can use a proprietary voice frame protocol to ensure complete decoupling. When any link malfunctions due to external electromagnetic interference, hardware failure, or channel congestion, the other links can still maintain stable operation.

[0037] Optionally, any vehicle in the fleet may include at least one of a transmitting module and a receiving module, which may include a data transmitting module and a data module to transmit and receive data via a data link, and may also include a voice transmitting module and a voice receiving module to transmit and receive data via a voice link. For example, the voice module may be a stand-alone digital intercom module (such as a dedicated ISM band digital intercom module).

[0038] Optionally, in response to receiving a first data packet sent by the first vehicle from the data link, the original radio frequency signal of the data packet can be captured and parsed by the data receiving module. This parsing can be performed autonomously by the data receiving module or by transmitting the data stream to the vehicle's main control module for parsing.

[0039] Optionally, the first data packet may be used to indicate the following information, including but not limited to: the identity identifier of the first vehicle, the location information of the first vehicle, and the verification identifier of the first vehicle.

[0040] Optionally, the parsing result of the first data packet can be used to identify whether the first vehicle belongs to the fleet and obtain the location data of the first vehicle. If the first vehicle is identified as belonging to the fleet and the location data of the first vehicle is parsed from the first data packet, the location point of the first vehicle can be rendered on the pre-loaded area map of the vehicle based on the location data of the first vehicle.

[0041] Optionally, the positioning data of the first vehicle can be latitude and longitude coordinates, or other forms of coordinate data; this embodiment does not limit this. This coordinate data can be written to a local collaborative database as a real-time location update source. An embedded offline map engine can be invoked to map the parsed vehicle coordinates to pixel positions in the corresponding map coordinate system based on the regional map data, and the location of the first vehicle can be rendered in the map interface. The update frequency is consistent with the data packet reception cycle.

[0042] Optionally, the aforementioned regional map can be a pre-loaded offline map or an online map that is periodically stored and updated; this embodiment does not impose any limitations on this.

[0043] Optionally, the location of the first vehicle can be rendered as a dynamic icon on the pre-loaded area map of this vehicle, or as text, or in other forms. This embodiment does not limit this.

[0044] Optionally, in response to receiving a second data packet sent by the second vehicle from the voice link, the data packet can be received and parsed by a voice receiving module. This module can use a dedicated voice codec protocol, and the data packet is encapsulated into a time-slot frame structure that conforms to the voice communication standard. It can be parsed autonomously by the voice receiving module, or the data stream can be transmitted to the vehicle's main control module for parsing.

[0045] Optionally, the second data packet may be used to indicate the following information, including but not limited to: the identity identifier of the second vehicle, the location information of the second vehicle, and the verification identifier of the second vehicle.

[0046] Optionally, if it is identified that the second vehicle belongs to the convoy and the voice data of the second vehicle is parsed from the second data packet, the voice data of the second vehicle can be played through the voice playback unit of this vehicle. This can be done by sending the voice data stream to a digital audio decoder to restore it to a PCM audio signal, and then driving the built-in speaker unit of this vehicle for real-time playback via an audio amplification circuit. The parsing and playback process of the voice data is completely independent of the location processing flow of the data link, and there is no resource conflict between the two at the data path, interrupt priority, and task scheduling levels.

[0047] Through the embodiments of this application, the communication link between different vehicles in a fleet includes a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link is physically isolated from the data link. In response to receiving a first data packet from a first vehicle from the data link, the first data packet is parsed. If it is identified that the first vehicle belongs to the fleet and the location data of the first vehicle is parsed from the first data packet, the location point of the first vehicle is rendered on the pre-loaded area map of this vehicle based on the location data of the first vehicle. In response to receiving a second data packet from a second vehicle from the voice link, the second data packet is parsed. If it is identified that the second vehicle belongs to the fleet and the voice data of the second vehicle is parsed from the second data packet, the voice data of the second vehicle is played through the voice playback component of this vehicle. This solves the problem of poor stability in vehicle interaction methods within a fleet in related technologies and achieves the effect of improving the stability of vehicle interaction.

[0048] In one exemplary embodiment, the communication link further includes a video link, and the voice link is physically isolated from the video link;

[0049] The above methods also include:

[0050] In response to receiving a third data packet from the first vehicle via the video link, the third data packet is parsed.

[0051] When vehicle video data is parsed from the third data packet, the vehicle video data is displayed in a video window on the area map. The vehicle video data is either the video data of the first vehicle or the video data of an external device associated with the first vehicle. On the area map, an association marker is displayed between the location point of the first vehicle and the video window.

[0052] Optionally, the vehicle's communication link may include a separate video link, which may employ a dedicated digital video transmission system (such as DJI O3 / Walksnail) operating in a frequency band completely different from the data link and voice link, and may employ a proprietary low-latency digital video transmission protocol.

[0053] Correspondingly, the vehicle's video communication module may include, but is not limited to, radio frequency front-end, modem module, encoder and antenna system. The video communication module may be physically isolated from the hardware components of the data link and voice link. The communication protocol stack of the video link may not intersect with the data link and voice link at the physical layer, link layer and application layer, ensuring that the operation of the other links is not affected when any link is subjected to electromagnetic interference, signal blockage or hardware failure.

[0054] Optionally, in response to receiving a third data packet sent by the first vehicle from the video link, the radio frequency signal of the data packet can be captured and parsed by the video receiving module. The parsing process may include, but is not limited to, frame synchronization, channel decoding and video stream restoration, and can output a video frame sequence with specific encoding.

[0055] Optionally, the parsing result of the third data packet can be verified. If the verification passes and the video stream data is complete, the video data stream can be sent to the embedded graphics processing unit or other video decoding core for real-time decoding and frame rate reconstruction, generating an independent video window in the display interface.

[0056] Optionally, the video window can be fixedly deployed in a preset area of ​​the offline map interface, or it can be deployed in a movable preset area, or it can be deployed in a corresponding area calculated in real time based on the location of the first vehicle on the map. Its position can be spatially associated with the location of the first vehicle on the map. For example, a dynamic line can be drawn between the location of the first vehicle on the map and the corresponding video window as an association marker. This marker adopts the form of a semi-transparent vector line or arrow, and its color is consistent with the color of the icon of the first vehicle on the map, which is used to establish a visual spatial correspondence. It can also be associated in other forms, which are not limited in this embodiment.

[0057] Optionally, the aforementioned vehicle video data can be video data from the first vehicle or video data from external devices associated with the first vehicle. It can originate from the front-view or side-view cameras mounted on the first vehicle itself, or from external vision devices (such as drones, helmet cameras, or remote sensing probes) bound to the first vehicle via wired or wireless interfaces. The source can be identified through the device metadata field within the video data packet, and a device identifier can be marked on the border of the video window for distinction.

[0058] Optionally, the associated marker can be continuously displayed only when the video stream is valid and the vehicle identity matches. Once the video link is interrupted or the vehicle identity becomes invalid, the video window can be automatically grayed out and the associated marker disappears synchronously, ensuring the semantic consistency between the map and video information.

[0059] This embodiment improves the stability and real-time performance of vehicle interaction by transmitting and receiving video data via a video link and displaying it accordingly.

[0060] In one exemplary embodiment, after parsing the first data packet, the method further includes:

[0061] If the first vehicle is identified as belonging to a convoy and its location data is parsed from the first data packet, in response to the relay count parameter in the first data packet indicating that the number of relays is less than a preset threshold, the relay count parameter in the first data packet is updated, and the updated first data packet is broadcast within the data link.

[0062] Optionally, the first data packet can also be used to indicate the relay count parameter. If it is identified that the first vehicle belongs to the fleet and the location data of the first vehicle is successfully parsed from the first data packet, the relay count parameter carried in the data packet can be parsed.

[0063] In off-road environments without network coverage, communication systems may face challenges such as limited communication distance and signal attenuation and link interruptions due to terrain obstruction. Constrained by the propagation characteristics of the ISM band, the reliable communication distance of a single-hop ELRS link is significantly reduced in complex terrains such as mountains, dense forests, or canyons, and issues such as multipath fading, shadowing effects, and non-line-of-sight communication failures also exist. Traditional point-to-multipoint (P2MP) broadcast architectures are prone to issues where some vehicles cannot receive critical positioning data when the convoy size increases or the terrain becomes complex.

[0064] Optionally, the vehicle may also include a relay function module. When a vehicle (relay node) receives a data packet from another vehicle that meets the verification requirements (such as the first data packet), if the vehicle ID of the data packet is not directly perceived by this vehicle (i.e., it is not a broadcast source of this vehicle), and its hop number segment has not reached the preset maximum value, then after completing the local collaborative database update, the vehicle can re-encapsulate the data packet, increment the hop number segment, and forward it through its own ELRS transmission module.

[0065] Here, the relay count parameter can be set to zero by the initial sender of the data packet at the time of generation, and its value can be incremented by one each time it is received and rebroadcast by a vehicle in the convoy.

[0066] Optionally, the currently parsed relay count can be compared with a preset relay count threshold. If the relay count parameter indicates that the number of relays is less than the preset threshold, the data packet is determined to still have propagation value and has not reached the propagation limit. At this time, after the system completes the update of the vehicle positioning data and map rendering in the local collaborative database, it performs an atomic increment operation on the relay count field of the data packet, that is, it overwrites the original relay count value in the original data packet structure and updates it to the original value plus one. At the same time, the system retains the other fields of the data packet unchanged, including vehicle ID, locator coordinates, status information and checksum, and recalculates the checksum to ensure data integrity.

[0067] Optionally, the updated data packet can be repackaged into a specific format by the vehicle's transmitter module and retransmitted in the data link via the P2MP broadcast mechanism. This broadcast behavior does not depend on a central node; all platoon members within the bound domain can receive and process the updated data packet. This mechanism can form a decentralized broadcast diffusion mechanism, ensuring that location information is quickly and reliably propagated to all vehicles in the platoon.

[0068] Optionally, any vehicle can have relay capabilities without requiring a designated master node or coordinator. During transmission, the hop count increases with each relay vehicle. The path can be dynamically determined by the signal strength and reception success rate of the communication link, forming a multi-path, adaptive topology. For example, if there is a mountain obstructing the connection between the lead vehicle and the tail vehicle, but two intermediate vehicles can establish links with both ends, data can propagate simultaneously through two paths, improving transmission reliability.

[0069] To prevent broadcast storms and avoid bandwidth congestion and resource waste caused by data packets endlessly looping or being repeatedly forwarded in the network, a preset threshold for the number of times can be set. This value can be designed according to the typical fleet size and the maximum expected communication radius to ensure that the entire fleet can still be covered in complex terrain, while avoiding ineffective propagation.

[0070] Optionally, forwarding of a data packet can be stopped after the number of relays reaches a threshold.

[0071] This embodiment, by introducing a multi-level dynamic relay mechanism, can improve the stability of vehicle interaction in complex terrain, while suppressing the unlimited spread of data packets in a network-free environment, avoiding network congestion and waste of channel resources, and improving the information coverage and robustness of the fleet coordination system in complex terrain.

[0072] In an exemplary embodiment, each vehicle in the fleet is equipped with a preset synchronization word, and each vehicle is used to broadcast data packets within the data link. The data packets broadcast by each vehicle within the data link include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets broadcast by each vehicle within the data link is a CRSF telemetry frame.

[0073] In response to receiving a first data packet from the first vehicle via the data link, the first data packet is parsed, including:

[0074] In response to receiving a first data packet from the first vehicle from the data link, the synchronization word in the first data packet is matched with a preset synchronization word to identify whether the first vehicle belongs to the convoy;

[0075] If the synchronization word in the first data packet matches the preset synchronization word, the target data frame in the first data packet is parsed to obtain the positioning data of the first vehicle.

[0076] Optionally, each vehicle in the fleet can be configured with the same preset synchronization word and broadcast data packets within the data link. This can be achieved by continuously sending data packets containing location information in a one-way broadcast mode via the preset data link, thereby constructing a decentralized, dependency-free, high-concurrency real-time collaborative positioning communication network. Here, the preset synchronization word refers to a fixed-length bit sequence pre-configured and embedded in all communication nodes, located at the beginning of the data packet. It can be used to identify the start boundary of the data frame, enabling the receiving end to achieve physical layer synchronization and legal frame identification. The preset synchronization word can be embedded in firmware before deployment, and the transmitters and receivers of all vehicles can be configured with the same preset synchronization word.

[0077] Optionally, each vehicle's communication system may include a data transmitting module and a data receiving module.

[0078] Optionally, the vehicle's transmitter module is configured to send data packets via a pre-defined data link in a one-way broadcast manner. One-way broadcast refers to a communication mode where data transmission is initiated independently by the transmitter, requiring no response, acknowledgment, retransmission, or connection establishment from the receiver. The broadcast process is a one-way transmission mode; that is, the transmitter module only sends data, does not listen for any wireless signals, does not wait for acknowledgment, does not establish a connection, and does not require relay forwarding.

[0079] Optionally, the vehicle's data receiving module can be installed inside the vehicle, receiving wireless radio frequency signals broadcast from the transmitting modules of other vehicles in the fleet via an antenna, and outputting a demodulated digital serial data stream.

[0080] Optionally, each vehicle's data packet may also include a preset synchronization word and a data frame for carrying positioning data. The data frame in each vehicle's data packet is a CRSF telemetry frame. Here, CRSF (Crossfire Serial Format) is a serial telemetry data encapsulation protocol in the ELRS protocol stack. It can be used as a serial communication protocol framework for transmitting control commands and telemetry data between the transmitter and receiver. Its data frame structure follows a unified encoding standard and supports time-division multiplexing transmission of multiple types of data on a single UART link.

[0081] Optionally, the positioning and status information of all vehicles can be encapsulated as CRSF Custom Telemetry frames. Here, a Custom Telemetry frame is a frame structure for transmitting custom telemetry data, and its frame type field can be fixed to distinguish it from standard remote control channel frames, link status frames, or other protocol-defined frame types.

[0082] Optionally, the data frame may include, but is not limited to: a unique vehicle ID (uint8_t), encoded GPS coordinates (uint32_t x2), compressed vehicle status (uint8_t), and a data checksum (uint16_t).

[0083] In this embodiment, when a vehicle receives the first data packet sent by any vehicle, it can first scan the physical layer frame header of the data packet byte by byte, extract the synchronization word located at the beginning of the frame, and compare the extracted synchronization word in the first data packet bit by bit with the preset synchronization word stored locally.

[0084] Optionally, in response to a match between the synchronization word in the first data packet and a preset synchronization word, i.e., if the two are completely identical across all bits, it can be determined that the data packet originates from a transmitting node within the same communication domain that sends data via a specific data link, thus satisfying the protocol admission conditions. Under this premise, the subsequent data frame parsing process can be initiated.

[0085] Optionally, in response to a mismatch between the synchronization word in the first data packet and a preset synchronization word, i.e., if there is any bit difference between the two, the data packet can be determined to be an illegal signal, an interference frame, or sent by a node not belonging to this system. In this case, the data packet can be immediately discarded and subsequent processing terminated, or alarm measures can be taken, etc., which are not limited in this embodiment.

[0086] Optionally, after a successful synchronization word match, the structure of subsequent CRSF frames in the data packet can also be identified. The payload of these frames may include vehicle identification, punctuated coordinate data, status flags, and check fields.

[0087] Optionally, the first data frame in the first data packet can be parsed to obtain the vehicle identifier and location data of the first vehicle. This can be done by parsing the content of each field in the first data frame, extracting the vehicle identifier to uniquely identify the first vehicle, extracting the longitude and latitude data after fixed-point encoding, and then performing a reverse decoding operation to restore the integer coordinate values ​​to floating-point geographic coordinates to obtain the precise geographical location information of the first vehicle.

[0088] This embodiment improves the reliability and stability of data transmission in the data link by matching and recognizing based on preset synchronization words and parsing based on telemetry frames.

[0089] In one exemplary embodiment, rendering the location points of the first vehicle on a pre-loaded area map based on the positioning data of the first vehicle includes:

[0090] Based on the vehicle identifier of the first vehicle, the positioning data of the first vehicle is updated to the local collaborative database of this vehicle. The collaborative database is used to store the positioning data of each of all identified vehicles. All identified vehicles are vehicles in the fleet that have been identified by this vehicle. This vehicle is a vehicle in the fleet.

[0091] Based on the collaborative database, the location points of all identified vehicles are rendered on the pre-loaded regional map of this vehicle, where all identified vehicles include the first vehicle.

[0092] Optionally, the location data of the first vehicle can be updated to the local collaborative database of the vehicle based on the vehicle identifier of the first vehicle. The collaborative database is used to store the location data of each of the identified vehicles. The collaborative database can be a structured memory data structure running in the core host microcontroller unit.

[0093] Optionally, in the collaborative database, each entry can use the vehicle ID as a unique key to associate and store the latest data set of the corresponding vehicle, which may include, but is not limited to: longitude, latitude, vehicle status, data reception time, and number of relays.

[0094] Optionally, the collaborative database can only include vehicle information that has been confirmed as a fleet member by the vehicle through synchronization word matching and CRC check. Data packets that fail authentication or verification will not be written, ensuring the integrity and reliability of the data in the database.

[0095] Optionally, the collaborative database can be a real-time updated local state cache, designed as a decentralized, masterless architecture that does not rely on external servers or network synchronization and is entirely maintained independently by the vehicle. Its storage capacity can be pre-allocated based on the maximum size of the fleet, and when the capacity is exceeded, it can overwrite the oldest records, ensuring that the database always retains the latest and most active fleet member states.

[0096] Optionally, all identified vehicles are those vehicles in the fleet that have been identified by this vehicle.

[0097] Optionally, all identified vehicles can be the set of fleet members whose data packets were successfully received by the vehicle, whose identity was verified, and whose valid location data was parsed within the current communication cycle.

[0098] Optionally, the location data of the first vehicle can be written into the database after being parsed, replacing or adding entries for the corresponding vehicle ID to achieve dynamic updates.

[0099] Optionally, based on the location data of all identified vehicles stored in the collaborative database, the location points of all identified vehicles can be rendered on the pre-loaded regional map of this vehicle. This can be done by calling an embedded offline map engine to map the latitude and longitude coordinates of each vehicle to the pre-loaded regional map coordinate system, generating corresponding location point icons. The update frequency can be synchronized with the data packet reception cycle. All identified vehicles can participate in the rendering, including the first vehicle and other convoy members that have successfully communicated. Unidentified or outdated vehicles can be omitted from the map interface to avoid misleading information.

[0100] This embodiment enables real-time collaborative perception of multiple targets within the vehicle through a collaborative database, achieving data localization and ensuring real-time, continuous, and accurate data transmission and storage even in environments without cellular networks.

[0101] In one exemplary embodiment, the collaborative database records the latest location data for each identified vehicle and a set of historical location data for each identified vehicle;

[0102] Based on the collaborative database, the location points of all identified vehicles are rendered on the pre-loaded area map of this vehicle, including:

[0103] Based on the latest location data of each identified vehicle, the latest location of each identified vehicle is rendered on the regional map using preset vehicle icons;

[0104] Based on a set of historical location data for each identified vehicle, update the trajectory of each identified vehicle rendered on the regional map.

[0105] In this embodiment, the collaborative database can record the latest positioning data for each identified vehicle and a set of historical positioning data for each identified vehicle. The latest positioning data can include vehicle identifier, longitude, latitude, altitude information, and timestamp, used to represent the vehicle's current spatial location in real time; historical positioning data can be stored in chronological order, with each point containing a corresponding timestamp and coordinate information.

[0106] Optionally, based on the latest location data of each identified vehicle, the longitude and latitude values ​​in the latest location data can be extracted, and the coordinate point can be mapped to the geographic coordinate system of the regional map. The latest location of each identified vehicle can be rendered on the regional map using preset vehicle icons (different vehicles can be identified by different colors or shapes).

[0107] Optionally, based on a set of historical positioning data for each identified vehicle, all location points in the historical positioning data of each identified vehicle can be extracted, and adjacent coordinate points can be connected in chronological order to generate the running trajectory of each identified vehicle.

[0108] Optionally, the aforementioned location points and trajectory lines can be rendered in independent vector layers of the regional map, without being mixed with the base terrain layer, and support independent start / stop and transparency adjustment. The map engine can trigger a redraw after each collaborative database update, refreshing only the changed vehicle positions and trajectory segments, avoiding full map re-rendering.

[0109] This embodiment improves the convenience and real-time performance of vehicle location data by updating the map in real time to identify the vehicle's location on a pre-loaded area map, thereby optimizing the user experience.

[0110] In one exemplary embodiment, if the synchronization word in the first data packet matches a preset synchronization word, parsing the target data frame in the first data packet includes:

[0111] If the synchronization word in the first data packet matches the preset synchronization word, the first check value is extracted from the target data frame.

[0112] A second check value is generated based on the payload portion of the target data frame.

[0113] If the first check value and the second check value match, the positioning data of the first vehicle is parsed from the payload section.

[0114] Optionally, the first data frame may include a frame header, a payload, and an additional check field. In response to a match between the synchronization word in the first data packet and a preset synchronization word, a first check value can be extracted from the first data frame. This first check value may be extracted from the check field attached to the first data frame. The first check value may be a fixed-length checksum generated at the transmitting end according to a preset check algorithm and embedded at the end of the data frame. Its length is 16 bits, and it is used to characterize the integrity status of the data frame before transmission. The check range may include, but is not limited to, the frame header, vehicle ID, encoded latitude and longitude coordinates, vehicle status field, and length identifier of the data frame.

[0115] Optionally, the payload portion of the first data frame can be extracted according to the protocol definition. This portion may include fields such as vehicle identification, geodetic coded longitude and latitude coordinates, and vehicle status flags. A second checksum can be generated by performing byte-by-byte calculations on the extracted payload portion, using the same checksum algorithm as the transmitting vehicle.

[0116] Optionally, the first check value and the second check value can be checked for matching. For example, the second check value can be compared bit-by-bit with the original check value (i.e., the first check value) embedded by the transmitter in the data frame. If the first check value and the second check value are completely consistent, it can be determined that no bit errors or data corruption occurred during the wireless transmission of the data frame, and the data integrity is verified. At this point, the data parsing process can continue to be executed to parse the vehicle identifier of the target vehicle and the location data of the first vehicle from the payload portion.

[0117] Optionally, if the first checksum and the second checksum do not match, the data frame can be determined to be abnormal (e.g., due to channel interference, electromagnetic interference, or signal attenuation). In this case, the frame can be discarded, subsequent field parsing can be omitted, and the collaborative database can be left unupdated to prevent erroneous location data from interfering with map rendering and collaborative decision-making. The vehicle receiving module can continuously monitor subsequent data frames until it receives the next new data packet with a matching synchronization word that passes the checksum.

[0118] In this embodiment, by verifying the first data frame in the first data packet, real-time performance and data reliability can be guaranteed.

[0119] In one exemplary embodiment, if the synchronization word in the first data packet matches a preset synchronization word, parsing the target data frame in the first data packet includes:

[0120] If the synchronization word in the first data packet matches the preset synchronization word, the initial positioning data is extracted from the positioning data field of the target data frame.

[0121] Perform reverse localization decoding on the initial positioning data to restore the initial positioning data to the positioning data of the first vehicle.

[0122] In this embodiment, in response to the synchronization word in the first data packet matching the preset synchronization word, the vehicle identifier of the first vehicle can be extracted from the vehicle identifier field of the first data frame, and the initial positioning data can be extracted from the positioning data field of the first data frame. The vehicle identifier can be extracted according to the byte offset defined by the protocol. For example, it can be located at the beginning of the payload and occupy 1 byte.

[0123] Alternatively, initial positioning data can be extracted from the positioning data field of the first data frame. For example, longitude and latitude coordinates can be extracted. The initial positioning data can be data represented in a fixed-point encoding format.

[0124] Corresponding to the above initial positioning data, reverse localization decoding can be performed on the initial positioning data to restore the initial positioning data to the positioning data of the first vehicle.

[0125] Alternatively, a 32-bit integer division instruction or a fixed-point division optimization algorithm can be used to restore the longitude and latitude integers extracted from the data frame to their corresponding floating-point values.

[0126] Optionally, if the transmitting module uses other compression algorithms, the receiving module of this vehicle can use corresponding other reverse decoding algorithms to perform reverse decoding in order to restore the initial positioning data to the positioning data of the first vehicle.

[0127] In this embodiment, reverse fixed-point decoding is used to achieve the transmission and corresponding decoding of integer encoding, reducing bandwidth consumption while achieving high-precision positioning.

[0128] In one exemplary embodiment, each vehicle is equipped with an on-board data processing terminal and a processing unit, wherein the extraction of the synchronization word from the first data packet and the parsing of the target data frame are performed by the processing unit of the vehicle.

[0129] The above methods also include:

[0130] The vehicle's positioning data is obtained by acquiring the positioning data collected by the vehicle's positioning module through the vehicle's onboard data processing terminal. The positioning data of the vehicle is a 64-bit double-precision floating-point number.

[0131] The vehicle's onboard data processing terminal uses fixed-point encoding to convert the vehicle's location data into a 32-bit integer, resulting in compressed location data. This compressed location data is then encapsulated into the fourth data packet to be broadcast by the vehicle.

[0132] The vehicle's onboard data processing terminal broadcasts a fourth data packet within the data link.

[0133] Optionally, each vehicle is equipped with an onboard data processing terminal and a dedicated processing unit. These two components can be functionally separated in their hardware architecture, functioning as independent hardware units that interact via the UART / CRSF protocol. The vehicle data processing terminal can perform data acquisition, encoding, and encapsulation, while the processing unit can extract synchronization words from the first data packet and parse the target data frame. When the data link receives the first data packet, the processing unit first performs synchronization word matching on the original bitstream, comparing a preset synchronization word sequence bit by bit using a sliding window. Upon successful matching, it calls the CRC check module to verify the integrity of the data frame. Subsequently, based on the offset and field structure defined by the protocol, it extracts the encoded positioning data field from the payload of the target data frame, completing the parsing process. This process is executed independently by the processing unit, unaffected by other tasks on the onboard data processing terminal, ensuring real-time performance and deterministic response.

[0134] In this embodiment, each vehicle can be equipped with an onboard data processing terminal and processing unit. The processing unit of the vehicle can perform tasks such as extracting synchronization words from the first data packet, parsing the first data frame, updating the positioning data of the first vehicle to the collaborative database, and rendering the location points of each identified vehicle on the regional map. The processing unit can be composed of an application processor and a coprocessor, and has independent storage, computing, and graphics rendering capabilities. It is responsible for receiving, verifying, decoding, and visualizing telemetry data from other vehicles.

[0135] Optionally, the processing unit may include a transmitting module and a receiving module, used for transmitting data packets and receiving data packets, respectively, for example, Figure 3 As shown, the vehicle may include an on-board data processing terminal and a processing component, wherein the processing component may include a transmitting module and a receiving module.

[0136] Optionally, the positioning data output by the positioning module mounted on the vehicle can be obtained through the vehicle's onboard data processing terminal. For example, it can collect longitude, latitude, and altitude data from the GPS / GNSS module.

[0137] Optionally, the vehicle's operating status information, including but not limited to alarm ID, throttle opening, vehicle speed, gear status, and braking signal, can also be obtained from the CAN bus via the vehicle's onboard data processing terminal.

[0138] Optionally, the positioning data can be compressed using fixed-point encoding via the vehicle's onboard data processing terminal. For example, the longitude and latitude values ​​can be 64-bit double-precision floating-point positioning data. Correspondingly, the longitude and latitude values ​​can be calculated separately and rounded to 32-bit integers to generate compressed positioning data.

[0139] Optionally, the vehicle's onboard data processing terminal can encapsulate the compressed positioning data into the fourth data packet to be sent by the vehicle. This can be achieved by encapsulating the compressed positioning data, the vehicle's identification, vehicle status information, and CRC-16 checksum into a Custom Telemetry data frame conforming to the CRSF protocol specification, thus forming the fourth data packet.

[0140] Optionally, the fourth data packet can be sent via the vehicle's onboard data processing terminal in a one-way broadcast manner within a preset communication channel. This can be achieved by the onboard data processing terminal outputting the fourth data packet via a UART interface to the transmitter of the processing unit, and continuously sending it via one-way broadcast within the preset communication channel. This broadcast process does not rely on an acknowledgment mechanism, does not establish a connection, and does not perform retransmissions. All vehicles use the same preset synchronization word to ensure that all receivers can simultaneously parse data from any transmitter.

[0141] Optionally, the vehicle-mounted data terminal can also receive data packets from other vehicles and, when preset forwarding conditions are met, rebroadcast the received data packets to the wireless channel.

[0142] In this embodiment, by compressing and encapsulating the location data before sending it, bandwidth consumption can be reduced and data reliability can be improved.

[0143] In an exemplary embodiment, the fleet includes a first type of vehicle and a second type of vehicle. The first type of vehicle is a vehicle used to synchronize the parameter values ​​of vehicle state parameters to the second type of vehicle. The second type of vehicle is a vehicle used to acquire the parameter values ​​of the synchronized vehicle state parameters of the first type of vehicle. The vehicle state parameters of the first type of vehicle are used to characterize the vehicle state of the first type of vehicle.

[0144] If the synchronization word in the first data packet matches the preset synchronization word, the target data frame in the first data packet is parsed, including: if the first vehicle is a first type of vehicle and the synchronization word in the first data packet matches the preset synchronization word, the positioning data of the first vehicle and the parameter values ​​of the vehicle status parameters of the first vehicle are parsed from the target data frame.

[0145] After parsing the target data frame in the first data packet, the method further includes updating the displayed vehicle status of the first vehicle on the area map based on the parameter values ​​of the vehicle status parameters of the first vehicle.

[0146] Optionally, the fleet may include a first type of vehicle and a second type of vehicle. The first type of vehicle is used to synchronize the parameter values ​​of the vehicle status parameters to the second type of vehicle. The second type of vehicle is used to obtain the parameter values ​​of the vehicle status parameters synchronized by the first type of vehicle. The vehicle status parameters of the first type of vehicle are used to characterize the vehicle status of the first type of vehicle. That is, the first type of vehicle can be the publisher of the vehicle status parameters, and the second type of vehicle can be the receiver of the vehicle status parameters. The vehicle status parameters of the first type of vehicle are used to characterize its operating status. The second type of vehicle can obtain the real-time values ​​of the above status parameters by receiving and parsing the data packets broadcast by the first type of vehicle, and use them for collaborative situational awareness, risk warning and path decision-making.

[0147] For example, in a training and learning scenario on an off-road section, the first type of vehicle can be a training vehicle, and the second type of vehicle can be a student vehicle. The vehicle status parameters of the first type of vehicle can be collected by the on-board data processing terminal of the training vehicle and encapsulated in a data frame, which is then broadcast to all nodes in the convoy as collaborative information.

[0148] Optionally, if the first vehicle is a first type of vehicle, when the processing unit detects that the synchronization word of the first data packet is completely consistent with the system preset synchronization word, the first data frame can be parsed. The vehicle identifier of the first vehicle, the positioning data of the first vehicle, and the parameter values ​​of the vehicle status parameters of the first vehicle can be parsed from the first data frame. The parsing process is similar to that in the aforementioned embodiments.

[0149] Optionally, after parsing the first data frame in the first data packet, the parameter values ​​of the vehicle status parameters of the first vehicle can be updated to the collaborative database based on the vehicle identifier of the first vehicle; based on the collaborative database, the vehicle status of the first vehicle displayed on the regional map can be updated.

[0150] Optionally, based on the vehicle identifier of the first vehicle obtained from the parsing, the corresponding vehicle record can be searched in the collaborative database; if the record does not exist, a new entry can be created.

[0151] Optionally, if a corresponding vehicle record is found, the extracted vehicle status parameter values ​​can be updated to the corresponding record, and the update process is similar to that in the aforementioned embodiments.

[0152] Optionally, based on the updated vehicle status parameters in the collaborative database, the icons of the target vehicles can be dynamically and visually updated using a regional map rendering engine. In the case where the first type of vehicle is a training vehicle and the second type is a student vehicle, this ensures that students can instantly perceive the operational intentions and abnormal behaviors of the training vehicle during training, achieving immersive collaborative teaching based on spatial location.

[0153] In this embodiment, without changing the decentralized P2MP architecture, the vehicle interaction scheme within the fleet can be applied to training and learning modes on off-road sections or other similar scenarios. The first type of vehicle acts as the instructor vehicle, and its operating parameters are recorded and broadcast in real time. The second type of vehicle acts as the trainee vehicle, and by receiving and analyzing the state parameters of multiple first-type vehicles, it achieves real-time reference and simulation learning of driving trajectories. This not only supports basic positioning and collaboration, but also enables the construction of a training closed loop of experience sharing and behavior imitation in complex off-road environments, significantly improving the overall operational efficiency and driving safety of the fleet.

[0154] Optionally, the second type of vehicles can also broadcast to each other, and the first type of vehicles can also receive data frames from other vehicles. This embodiment does not limit this.

[0155] In this embodiment, by using location-based bidirectional state perception and visualization collaboration, vehicle state parameters are actively encapsulated and broadcast in the first type of vehicles, and the state is automatically parsed and rendered in the second type of vehicles, which can improve the perception capability and efficiency of vehicles in the convoy.

[0156] In an exemplary embodiment, the fleet includes a first type of vehicle and a second type of vehicle. The first type of vehicle is a vehicle used to synchronize the parameter values ​​of vehicle state parameters to the second type of vehicle. The second type of vehicle is a vehicle used to acquire the parameter values ​​of the synchronized vehicle state parameters of the first type of vehicle. The vehicle state parameters of the first type of vehicle are used to characterize the vehicle state of the first type of vehicle.

[0157] The above methods also include:

[0158] When the vehicle is a Class 1 vehicle, the vehicle's location data and the parameter values ​​of the vehicle's status parameters are obtained, wherein the vehicle's status parameters include at least one of the following: throttle status parameters, brake status parameters, gear status parameters, and alarm status parameters.

[0159] The vehicle's location data and vehicle status parameter values ​​are encapsulated into the fifth data packet to be broadcast by the vehicle.

[0160] Broadcast the fifth data packet within the data link.

[0161] Similar to the previous embodiments, the fleet may include a first type of vehicle and a second type of vehicle. The first type of vehicle can be a publishing node for vehicle status parameters, used to actively broadcast its operating status to the second type of vehicle. The second type of vehicle can be a receiving node for status parameters, used to parse and visualize the status information from the first type of vehicle. The vehicle status parameters of the first type of vehicle can be used to accurately characterize its dynamic operating behavior and abnormal events, including but not limited to: throttle status parameters, brake status parameters, gear status parameters, and alarm status parameters.

[0162] When this vehicle is configured as a Class 1 vehicle, the vehicle's positioning data and vehicle status parameter values ​​can be collected in real time. This data can be collected by the vehicle's onboard data processing terminal from the positioning data output by the multi-mode GNSS module, including longitude, latitude, altitude, and timestamp.

[0163] Optionally, the vehicle status parameters can also be obtained, which can be obtained from the vehicle's CAN bus. The vehicle status parameters can include at least one of the following: throttle status parameters, which can be used to indicate the throttle pedal opening and are periodically sent by the electronic control unit via CAN messages; brake status parameters, which can be used to indicate the brake pedal activation status and braking force level; gear status parameters, which can be represented by a 4-bit code, with each gear code corresponding to different gear parameters, such as P (park), R (reverse), N (neutral), D (drive), 4L (low-speed four-wheel drive), etc.; and alarm status parameters, which can be used to correspond to different preset alarm events.

[0164] Optionally, the vehicle's location data and vehicle status parameter values ​​can be encapsulated into the fifth data packet to be transmitted by the vehicle. The fifth data packet can adopt the CRSF Custom Telemetry frame format, and its structure can be a fixed byte length, which may include, but is not limited to: vehicle identifier, locatorized longitude, locatorized latitude, locatorized altitude, vehicle status parameter bit fields, checksum protocol header and padding bytes. Among them, throttle, brake, gear, and alarm status can be compressed and encoded in a 1-byte status field in bit field form to avoid floating point or string transmission and maximize the utilization of ELRS telemetry bandwidth.

[0165] Optionally, after encapsulation, the fifth data packet can be sent in a one-way broadcast manner within a preset communication channel. This can be achieved by injecting the fifth data packet into the sending module of the processing unit through the UART interface, and then having the sending module continuously send it in a one-way broadcast manner within the preset communication channel. Correspondingly, all second-class vehicles within the communication coverage area can simultaneously receive the broadcast data packet and complete identification and parsing based on the synchronization word, thereby realizing the delay-free, decentralized, and fully distributed sharing of the status of first-class vehicles.

[0166] This embodiment allows for the early identification of vehicle status by synchronizing vehicle status parameters in real time, thereby improving vehicle safety.

[0167] In one exemplary embodiment, the CRSF telemetry frame has a frame type of 0x10; the data link uses a 2.4 GHz wireless communication band; and the CRSF telemetry frame has a transmission rate of not less than 500 Hz and a frame interval of not more than 2 milliseconds.

[0168] Optionally, the frame type field of the CRSF telemetry frame can be 0x10. This value can be defined according to the CRSF protocol specification to uniquely identify the data frame as a custom telemetry type, distinguishing it from remote control command frames, link status frames, or other standard telemetry data frames. During the decoding process, the vehicle's receiver can detect that the frame type field is 0x10 to determine that the frame contains vehicle positioning and status parameter information, thereby triggering the corresponding parsing and processing procedures.

[0169] Optionally, the preset communication channel can be in the 2.4GHz band, which can be an ISM wireless communication band. Dynamic channel switching can mitigate electromagnetic interference and ensure the stability of the communication link in complex electromagnetic environments. The center frequency, frequency hopping sequence, and number of channels of the communication channel can be determined by binding phrases and firmware configuration. All fleet nodes can use the same frequency planning parameters to achieve parallel communication of multiple nodes in the same frequency band.

[0170] Optionally, to adapt to existing communication protocols, the transmission rate of CRSF telemetry frames can be no less than 500Hz, that is, at least 500 telemetry data frames are sent per second, with a corresponding frame interval of no more than 2 milliseconds, to ensure that the data update frequency meets the system requirements for real-time collaborative positioning and status awareness. This frame rate can be driven by a timer in the vehicle's transmitter firmware, synchronously executing frame construction and transmission operations based on the system clock, without relying on external interrupts or software scheduling, thus ensuring time accuracy.

[0171] Alternatively, the transmission rate can be other values. For example, in order to reduce power consumption or prevent channel congestion, the transmission rate can be appropriately reduced, such as to 250Hz or even to 10Hz. This embodiment does not limit this.

[0172] In this embodiment, by using the transmission of CRSF telemetry frames and preset communication channels, it is possible to ensure that the end-to-end latency meets system requirements and reduce positioning delay.

[0173] In one exemplary embodiment, the preset synchronization word is a binding phrase burned into the wireless communication module of each vehicle; throughout the entire lifecycle of each vehicle from power-on to termination of operation, no handshake or reconnection process is performed with other vehicles in the fleet besides each vehicle.

[0174] Here, the binding phrase is a predefined string or binary key used to establish a secure communication domain between the vehicle's transmitter and receiver. It can be a fixed-length character sequence (usually ASCII text or a hexadecimal byte string) that serves as a unique identifier for both parties to communicate. It can be written into the vehicle's non-volatile memory by the user or other object when the devices are first paired. This embodiment does not limit this.

[0175] Optionally, the preset synchronization word can be a unique identifier embedded in the non-volatile memory of the wireless communication module equipped in each vehicle. It can be a predefined binary sequence, which can be written into the configuration register or firmware configuration area by a dedicated programming tool during the module manufacturing or field deployment stage, serving as the core basis for performing device identification and frame filtering.

[0176] Optionally, throughout the entire lifecycle of each vehicle from power-on to termination of operation, no handshake or reconnection process is performed with other vehicles in the fleet besides the vehicle itself. In related technologies, point-to-point communication typically requires a two-way handshake to complete device binding and link confirmation, including sending a binding request, receiving a response, and exchanging keys. When the communication link fails to receive due to interference, obstruction, or temporary loss of lock, a reconnection mechanism is also triggered, including attempting to switch channels, retransmit binding frames, and waiting for a timeout to retry.

[0177] In this embodiment, upon receiving any data frame that matches the preset synchronization word, no acknowledgment request is initiated, no authentication is performed, no session state is established, and no link maintenance signal is responded to. Even if reception fails, CRC check fails, or the channel is idle, no reconnection is initiated, no binding request is retransmitted, and no sleep or standby recovery state is entered. Instead, it remains in broadcast listening mode, waiting for the arrival of the next frame of data. Link recovery relies entirely on the natural retransmission mechanism of radio broadcasting (i.e., the transmitter continuously transmits at a fixed period), without requiring the receiver to participate in any recovery control. This avoids the necessary request and response interaction process in the communication protocol, enabling a completely decentralized, connectionless, and stateless broadcast network topology. Communication behavior is driven solely by the vehicle's transmitter, with the vehicle's receiver passively receiving data, without generating any bidirectional signaling overhead.

[0178] In this embodiment, each vehicle in the fleet can communicate with any other vehicle in the area. All vehicles have no central server or routing nodes, and all communication is direct broadcast, thereby achieving decentralized vehicle positioning.

[0179] This embodiment enables decentralized wireless collaboration by eliminating the need for handshake and reconnection processes with other vehicles in the fleet besides each individual vehicle.

[0180] The vehicle interaction method within a fleet in this application embodiment is explained below with reference to optional examples. In this embodiment, a vehicle may include a vehicle data processing terminal and a processing component. The vehicle data processing terminal may be a data buffer unit (DBU), which may include a microcontroller (MCU). The processing component may be a human-machine interface (HMI), which may include a transmitting module (i.e., an ELRS TX module, which is a wireless communication transmitting module installed on each vehicle for broadcasting CRSF data frames generated by the DBU through the 2.4GHz frequency band) and a receiving module (i.e., an ELRS RX module, which is a wireless communication receiving module installed on each vehicle for receiving CRSF data frames broadcast from all ELRS TX modules in the area and decoding them into location data). Figure 4 This is a flowchart illustrating the vehicle interaction method within a fleet in this optional example, such as... Figure 4 As shown, the process of vehicle interaction within this fleet may include the following steps:

[0181] Step S402: The vehicle MCU is running.

[0182] Step S404: High-frequency acquisition of GPS coordinates.

[0183] Step S406: Acquire CAN / other bus data.

[0184] Step S408, DBU data processing and encoding, may specifically include fixed-point encoding (converting high-precision floating-point GPS coordinates into 32-bit integers for efficient compression) and custom frame encapsulation (packaging vehicle ID, encoded coordinates, conversion and other verification data into data frames).

[0185] Step S410, ELRS TX wireless broadcast, may specifically include pushing the Custom Telemetry frame to ELRS TX via the data link through the CRSF protocol for P2MP broadcast (all vehicles are configured with the same binding phrase and are all used as independent transmitting units TX).

[0186] Step S412, ELRS RX module receives.

[0187] Step S414, verification and decoding.

[0188] Step S416, reverse fixed-point decoding, used to restore high-precision floating-point GPS coordinates.

[0189] Step S418, data splitting, that is, updating the parsed data to the collaborative database in real time according to the vehicle ID in the data.

[0190] Step S420, area map rendering, which renders the precise location and trajectory of the vehicle and teammates on the area map.

[0191] Step S422, video integration, which involves receiving the video stream from the FPV digital receiver (VRx) and displaying it in real time on the HMI screen via an interface.

[0192] Step S424, voice integration, that is, voice communication through a separate digital intercom module.

[0193] This optional example utilizes the ELRS link to reduce positioning data latency. By leveraging the ELRS P2MP telemetry broadcast mode, it enables simultaneous real-time sharing and rendering of the positions of all teammates, improving the convoy's safety prediction capabilities. Core data does not rely on public networks, ensuring uninterrupted functionality even in extreme environments. Fixed-point encoding is used to compress GPS coordinates, effectively utilizing the ELRS telemetry bandwidth to guarantee high-frequency, high-precision positioning data transmission, improving data transmission efficiency and reducing positioning latency.

[0194] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0195] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0196] According to another aspect of the embodiments of this application, a vehicle interaction device within a fleet is also provided. This vehicle interaction device can be used to implement the vehicle interaction method within a fleet provided in the above embodiments, and details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0197] Similar to the previous embodiments, the communication links between different vehicles in the fleet include a data link and a voice link. The vehicle interaction data link in the fleet is used to transmit location data, and the vehicle interaction communication link in the fleet is used to transmit voice data. The vehicle interaction voice link in the fleet is physically isolated from the vehicle interaction data link in the fleet. Figure 5 This is a structural block diagram of an optional vehicle interaction device within a fleet according to an embodiment of this application, such as... Figure 5 As shown, the vehicle interaction devices within the fleet include:

[0198] The processing unit 502 is configured to parse the first data packet in response to receiving a first data packet from the first vehicle via the data link; and to parse the second data packet in response to receiving a second data packet from the second vehicle via the voice link.

[0199] Display component 504 is used to display a preloaded area map; when it is identified that the first vehicle belongs to the convoy and the location data of the first vehicle is parsed from the first data packet, the location point of the first vehicle is rendered on the area map, wherein the location point of the first vehicle is rendered based on the location data of the first vehicle.

[0200] The voice playback component 506 is used to play the voice data of the second vehicle when it is recognized that the second vehicle belongs to the convoy and the voice data of the second vehicle is parsed from the second data packet.

[0201] It should be noted that the processing unit 502 in this embodiment can be used to execute the above steps S202 and S206, which have already been explained and will not be repeated here.

[0202] The embodiments provided in this application address the issue of poor stability in vehicle interaction methods within a fleet, which utilize communication links between different vehicles within a fleet, including a data link and a voice link. The data link transmits location data, and the communication link transmits voice data. The voice link is physically isolated from the data link. In response to receiving a first data packet from a first vehicle via the data link, the first data packet is parsed. If the first vehicle is identified as belonging to the fleet and its location data is parsed from the first data packet, the location point of the first vehicle is rendered on a pre-loaded area map of the vehicle based on the first vehicle's location data. In response to receiving a second data packet from a second vehicle via the voice link, the second data packet is parsed. If the second vehicle is identified as belonging to the fleet and its voice data is parsed from the second data packet, the voice data of the second vehicle is played through the vehicle's voice playback component. This approach solves the problem of poor stability in vehicle interaction methods within a fleet in related technologies, thereby improving the stability of vehicle interaction.

[0203] In one exemplary embodiment, the vehicle interaction device further includes a positioning antenna and a wireless communication antenna, which are mounted via a mast and are higher than the vehicle's body structure.

[0204] In one exemplary embodiment, the vehicle interaction device, except for the positioning antenna, wireless communication antenna, and mast, is encapsulated in the same housing.

[0205] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0206] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0207] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0208] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0209] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0210] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0211] Figure 6 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 6 As shown, the computer system 600 includes a Central Processing Unit (CPU) 601, which performs various appropriate actions and processes based on programs stored in ROM 602 or loaded into RAM 603 from storage section 608. Random Access Memory 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 606 is also connected to the bus 604.

[0212] The following components are connected to I / O interface 606: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 606 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0213] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions defined in the system of this application.

[0214] It should be noted that, Figure 6 The computer system 600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0215] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0216] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for vehicle interaction within a fleet, characterized in that, The communication links between different vehicles in the convoy include a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link is physically isolated from the data link. The method includes: In response to receiving a first data packet from the first vehicle from the data link, the first data packet is parsed; If the first vehicle is identified as belonging to the fleet and its location data is parsed from the first data packet, the location point of the first vehicle is rendered on the pre-loaded area map of the vehicle based on the location data of the first vehicle. In response to receiving a second data packet from the second vehicle from the voice link, the second data packet is parsed; If the second vehicle is identified as belonging to the fleet and its voice data is parsed from the second data packet, the voice data of the second vehicle is played through the voice playback component of the vehicle.

2. The method according to claim 1, characterized in that, The communication link also includes a video link, and the voice link is physically isolated from the video link; The method further includes: In response to receiving a third data packet from the first vehicle from the video link, the third data packet is parsed; When vehicle video data is parsed from the third data packet, the vehicle video data is displayed in a video window on the area map. The vehicle video data is either the video data of the first vehicle or the video data of an external device associated with the first vehicle. An association marker is displayed between the location point of the first vehicle and the video window on the area map.

3. The method according to claim 1, characterized in that, After parsing the first data packet, the method further includes: If the first vehicle is identified as belonging to the fleet and the location data of the first vehicle is parsed from the first data packet, in response to the relay count parameter in the first data packet indicating that the number of relays is less than a preset threshold, the relay count parameter in the first data packet is updated, and the updated first data packet is broadcast within the data link.

4. The method according to claim 1, characterized in that, Each vehicle in the convoy is equipped with a preset synchronization word. Each vehicle is used to broadcast data packets within the data link. The data packets broadcast by each vehicle within the data link include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets broadcast by each vehicle within the data link is a CRSF telemetry frame. The step of parsing the first data packet received from the data link from the first vehicle includes: In response to receiving the first data packet of the first vehicle from the data link, the synchronization word in the first data packet is matched with the preset synchronization word to identify whether the first vehicle belongs to the fleet; If the synchronization word in the first data packet matches the preset synchronization word, the target data frame in the first data packet is parsed to obtain the positioning data of the first vehicle.

5. The method according to claim 4, characterized in that, The step of rendering the location point of the first vehicle on the pre-loaded area map based on the location data of the first vehicle includes: Based on the vehicle identifier of the first vehicle, the location data of the first vehicle is updated to the local collaborative database of the vehicle. The collaborative database is used to store the location data of each of all identified vehicles. All identified vehicles are vehicles in the fleet that have been identified by the vehicle. The vehicle is a vehicle in the fleet. Based on the collaborative database, the location points of all identified vehicles are rendered on the pre-loaded regional map of the vehicle, wherein all identified vehicles include the first vehicle.

6. The method according to claim 5, characterized in that, The collaborative database records the latest location data of each identified vehicle and a set of historical location data for each identified vehicle. The step of rendering the location points of all identified vehicles on the pre-loaded area map of the vehicle, based on the collaborative database, includes: Based on the latest location data of each identified vehicle, the latest location of each identified vehicle is rendered on the area map using a preset vehicle icon; Based on a set of historical location data for each identified vehicle, the running trajectory of each identified vehicle rendered on the regional map is updated.

7. The method according to claim 4, characterized in that, When the synchronization word in the first data packet matches the preset synchronization word, parsing the target data frame in the first data packet includes: If the synchronization word in the first data packet matches the preset synchronization word, the first check value is extracted from the target data frame; A second check value is generated based on the payload portion of the target data frame; If the first check value and the second check value match, the positioning data of the first vehicle is parsed from the payload portion.

8. The method according to claim 4, characterized in that, When the synchronization word in the first data packet matches the preset synchronization word, parsing the target data frame in the first data packet includes: If the synchronization word in the first data packet matches the preset synchronization word, the initial positioning data is extracted from the positioning data field of the target data frame. The initial positioning data is subjected to reverse localization decoding to restore the initial positioning data to the positioning data of the first vehicle.

9. The method according to claim 4, characterized in that, Each vehicle is equipped with an on-board data processing terminal and processing components, wherein the extraction of the synchronization word in the first data packet and the parsing of the target data frame are performed by the processing components of the vehicle. The method further includes: The vehicle's positioning data is obtained by acquiring the positioning data collected by the vehicle's positioning module through the vehicle's on-board data processing terminal, wherein the vehicle's positioning data is a 64-bit double-precision floating-point number. The vehicle's onboard data processing terminal uses fixed-point encoding to convert the vehicle's location data into a 32-bit integer to obtain compressed location data, and then encapsulates the compressed location data into the fourth data packet to be broadcast by the vehicle. The fourth data packet is broadcast within the data link via the vehicle's onboard data processing terminal.

10. The method according to claim 4, characterized in that, The fleet includes a first type of vehicle and a second type of vehicle. The first type of vehicle is used to synchronize the parameter values ​​of the vehicle status parameters to the second type of vehicle. The second type of vehicle is used to obtain the parameter values ​​of the vehicle status parameters synchronized by the first type of vehicle. The vehicle status parameters of the first type of vehicle are used to characterize the vehicle status of the first type of vehicle. The step of parsing the target data frame in the first data packet when the synchronization word in the first data packet matches the preset synchronization word includes: parsing the positioning data of the first vehicle and the parameter values ​​of the vehicle status parameters of the first vehicle from the target data frame when the first vehicle is the first type of vehicle and the synchronization word in the first data packet matches the preset synchronization word. After parsing the target data frame in the first data packet, the method further includes: updating the displayed vehicle status of the first vehicle on the area map based on the parameter value of the vehicle status parameter of the first vehicle.

11. The method according to claim 4, characterized in that, The fleet includes a first type of vehicle and a second type of vehicle. The first type of vehicle is used to synchronize the parameter values ​​of the vehicle status parameters to the second type of vehicle. The second type of vehicle is used to obtain the parameter values ​​of the vehicle status parameters synchronized by the first type of vehicle. The vehicle status parameters of the first type of vehicle are used to characterize the vehicle status of the first type of vehicle. The method further includes: When the vehicle is a vehicle of the first type, the positioning data of the vehicle and the parameter values ​​of the vehicle status parameters of the vehicle are obtained, wherein the vehicle status parameters of the vehicle include at least one of the following: throttle status parameters, brake status parameters, gear status parameters, and alarm status parameters. The vehicle's location data and the vehicle status parameters are encapsulated into the fifth data packet to be broadcast by the vehicle. The fifth data packet is broadcast within the data link.

12. The method according to any one of claims 4 to 11, characterized in that, The CRSF telemetry frame has a frame type of 0x10; the data link uses a 2.4GHz wireless communication band; the CRSF telemetry frame has a transmission rate of not less than 500 Hz and a frame interval of not more than 2 milliseconds.

13. The method according to any one of claims 4 to 11, characterized in that, The preset synchronization word is a binding phrase burned into the wireless communication module of each vehicle; throughout the entire lifecycle of each vehicle from power-on to operation termination, no handshake or reconnection process is performed with other vehicles in the fleet besides each vehicle.

14. A vehicle interaction device within a fleet, characterized in that, The communication links between different vehicles in the convoy include a data link and a voice link. The data link is used to transmit location data, and the communication link is used to transmit voice data. The voice link is physically isolated from the data link. The vehicle interaction device includes: A processing unit is configured to parse the first data packet received from the data link from the first vehicle, and to parse the second data packet received from the voice link from the second vehicle. A display component is used to display a preloaded area map; when it is identified that the first vehicle belongs to the fleet and the location data of the first vehicle is parsed from the first data packet, the location point of the first vehicle is rendered on the area map, wherein the location point of the first vehicle is rendered based on the location data of the first vehicle; A voice playback component is used to play the voice data of the second vehicle when it is recognized that the second vehicle belongs to the fleet and the voice data of the second vehicle is parsed from the second data packet.

15. The vehicle interaction device within a fleet according to claim 14, characterized in that, The vehicle interaction device further includes a positioning antenna and a wireless communication antenna, which are mounted via a mast and are higher than the vehicle's body structure.

16. The vehicle interaction device within a fleet according to claim 15, characterized in that, The vehicle interaction device, except for the positioning antenna, the wireless communication antenna, and the mast, is encapsulated in the same housing.

17. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 13.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 13.

Images