Vehicle cooperative positioning method and device in vehicle fleet, storage medium and electronic equipment

Abstract

Embodiments of the present application provide a vehicle cooperative positioning method and device in a vehicle fleet, a storage medium and an electronic device, wherein each vehicle in the vehicle fleet is configured with a preset synchronization word, and a data packet of each vehicle includes the preset synchronization word and a data frame for carrying positioning data, and the data frame in the data packet of each vehicle is a CRSF telemetry frame; the method comprises: extracting the synchronization word in a first data packet of a target vehicle; in response to the synchronization word in the first data packet matching the preset synchronization word, analyzing a first data frame in the first data packet to obtain a vehicle identifier of the target vehicle and positioning data of the target vehicle; in a case where the vehicle identifier of the target vehicle and the positioning data of the target vehicle are obtained, updating the positioning data of the target vehicle to a cooperative database locally of the vehicle based on the vehicle identifier of the target vehicle; and based on the cooperative database, rendering a position point of each identified vehicle on a regional map preloaded in the vehicle.

Description

Technical Field

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

[0002] The cooperative positioning solutions for fleets typically rely on base stations and cloud servers for forwarding. However, these solutions will fail in remote areas without cellular network coverage. On the other hand, frequency band solutions that can work without a network have the problem of high data update latency, which cannot meet the needs of fleet cooperative positioning for real-time coordination and obstacle prediction. They also have poor data reliability and high positioning latency.

[0003] This shows that the relevant technologies suffer from high positioning latency when performing vehicle cooperative positioning in areas without cellular network coverage. Summary of the Invention

[0004] This application provides a vehicle cooperative positioning method and apparatus, storage medium and electronic device within a fleet, to at least solve the problem of high positioning latency in related technologies when performing fleet cooperative positioning in areas without cellular network coverage.

[0005] According to one aspect of the embodiments of this application, a vehicle cooperative positioning method within a fleet is provided. Each vehicle in the fleet is configured with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. The method includes: upon receiving a first data packet of a target vehicle from the preset communication channel, extracting the synchronization word from the first data packet; in response to a match between the synchronization word in the first data packet and the preset synchronization word, parsing the first data frame in the first data packet to obtain the vehicle identifier and positioning data of the target vehicle; upon obtaining the vehicle identifier and positioning data of the target vehicle, updating the positioning data of the target vehicle to the local cooperative database of the vehicle based on the vehicle identifier, wherein the cooperative database is used to store the positioning data of each of all identified vehicles, all identified vehicles being vehicles in the fleet that have been identified by the vehicle, and the vehicle being a vehicle in the fleet; and rendering the location points of each identified vehicle on a pre-loaded area map of the vehicle based on the cooperative database.

[0006] According to another aspect of the embodiments of this application, a vehicle cooperative positioning device for a fleet is also provided. Each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. The vehicle cooperative positioning device includes: a processing unit, used to extract the synchronization word from the first data packet when a first data packet of a target vehicle is received from the preset communication channel; and to parse the first data frame in the first data packet in response to a match between the synchronization word in the first data packet and the preset synchronization word, so as to obtain the vehicle location information of the target vehicle. The system retrieves vehicle identification and target vehicle location data. Upon obtaining the target vehicle's identification and location data, it updates the target vehicle's location data to the vehicle's local collaborative database based on the target vehicle's identification. This collaborative database stores the location data of each identified vehicle in the fleet. All identified vehicles are those identified by this vehicle within the fleet, and this vehicle is the one with the vehicle collaborative positioning device located within the fleet. Based on the collaborative database, the system renders the location points of each identified vehicle on a pre-loaded area map. A display component is used to display the area map and mark the rendered location points of each identified vehicle on the displayed area map.

[0007] In one exemplary embodiment, the vehicle cooperative positioning 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.

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

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

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

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

[0012] According to this application, each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. Each vehicle's data packet includes the 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. Upon receiving a first data packet from a target vehicle through the preset communication channel, the synchronization word in the first data packet is extracted. In response to a match between the synchronization word in the first data packet and the preset synchronization word, the first data frame in the first data packet is parsed to obtain the target vehicle's vehicle identifier and positioning data. Upon obtaining the target vehicle's vehicle identifier and positioning data, the positioning data of the target vehicle is updated to the vehicle's local cache based on the target vehicle's vehicle identifier. The system uses a shared database, where the collaborative database stores the location data of each identified vehicle in the fleet. All identified vehicles are those identified by this vehicle within the fleet, and this vehicle is one of the vehicles in the fleet. Based on the collaborative database, the location points of each identified vehicle are rendered on a pre-loaded area map. Since all vehicles in the fleet are configured with the same synchronization word, and data packets are sent via one-way broadcast within a specific communication channel, collaborative vehicle positioning can be achieved not only in areas without cellular network coverage but also through instantaneous capture and parsing of data packets based on the synchronization word, thereby reducing positioning latency. Therefore, this system can solve the problem of high positioning latency in fleet collaborative positioning in areas without cellular network coverage, achieving the effect of reducing positioning latency and improving positioning efficiency. Attached Figure Description

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

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

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

[0016] Figure 4 This is a schematic diagram of another optional vehicle cooperative positioning method within a fleet according to an embodiment of this application;

[0017] Figure 5This is a flowchart illustrating another optional vehicle cooperative positioning method within a fleet according to an embodiment of this application;

[0018] Figure 6 This is a structural block diagram of an optional vehicle cooperative positioning device within a fleet according to an embodiment of this application;

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

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

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

[0022] According to one aspect of the embodiments of this application, a vehicle cooperative localization method within a convoy is provided. Optionally, in this embodiment, the above-described vehicle cooperative localization method within a convoy 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.

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

[0024] Taking vehicle 102 as an example to execute the vehicle cooperative localization method within the fleet in this embodiment, Figure 2This is a flowchart illustrating an optional vehicle cooperative positioning method within a fleet according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0025] Step S202: Upon receiving the first data packet from the target vehicle via a preset communication channel, extract the synchronization word from the first data packet.

[0026] Step S204: In response to the synchronization word in the first data packet matching the preset synchronization word, the first data frame in the first data packet is parsed to obtain the vehicle identifier and the location data of the target vehicle.

[0027] Step S206: After obtaining the vehicle identifier and location data of the target vehicle, update the location data of the target vehicle to the local collaborative database of this vehicle based on the vehicle identifier of the target 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 this vehicle. This vehicle is a vehicle in the fleet.

[0028] Step S208: Based on the collaborative database, render the location points of each identified vehicle on the pre-loaded area map of this vehicle.

[0029] The vehicle cooperative positioning method within a fleet in this embodiment can be applied to the field of wireless communication, specifically to scenarios involving fleet cooperative positioning in areas without cellular network coverage.

[0030] The communication architecture upon which convoy collaborative positioning relies is difficult to fully utilize in environments with no or weak network coverage. For cellular network methods, GNSS positioning data is typically uploaded to a cloud server via cellular mobile communication networks through vehicle terminals or mobile devices. The server then distributes the data to other members of the convoy, requiring base stations and network infrastructure. In off-road, mountainous, desert, and polar regions with no base station coverage, cellular signals are insufficient, preventing the system from establishing a connection and causing positioning data interruptions and collaborative function failures. Even in peripheral coverage areas, significant network latency fluctuations and bandwidth limitations make it difficult to guarantee continuous and stable positioning data transmission. For methods using long-distance or Industrial, Scientific and Medical (ISM) band radio, point-to-point or point-to-multipoint location data broadcasting can be achieved through LoRa modulation in the ISM band. The transmission link is a local wireless direct connection, which has a certain network-free working capability. However, due to limitations in spreading factor and channel bandwidth, the communication rate is low, the data packet transmission cycle is long, and the air transmission delay is high. It cannot meet the real-time requirements for location synchronization and obstacle prediction. Furthermore, when multiple nodes broadcast concurrently, channel conflicts are prone to occur. It lacks an efficient scheduling mechanism, the network scale is limited, and it is difficult to achieve stable communication.

[0031] Alternatively, location data can be transmitted via satellite communication, i.e., via satellite link. However, its application is limited by the high cost of terminal equipment, extremely low communication bandwidth, significant signal delay, and problems such as signal blockage and multipath effect, which cannot meet the low latency requirements of real-time collaborative positioning.

[0032] This shows that the relevant technologies suffer from high positioning latency when performing vehicle cooperative positioning in areas without cellular network coverage.

[0033] To at least partially solve the aforementioned technical problems, in this embodiment, each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. Each vehicle's data packet includes the preset synchronization word and a data frame carrying positioning data. The data frame in each vehicle's data packet is a CRSF telemetry frame. Upon receiving a first data packet from a target vehicle via the preset communication channel, the synchronization word in the first data packet is extracted. In response to a match between the synchronization word in the first data packet and the preset synchronization word, the first data frame in the first data packet is parsed to obtain the target vehicle's vehicle identifier and positioning data. Upon obtaining the target vehicle's vehicle identifier and positioning data, the target vehicle's positioning data is updated based on the target vehicle's vehicle identifier. The system accesses a local collaborative database for this vehicle, which stores the location data of each of the identified vehicles in the fleet. All identified vehicles are those identified by this vehicle within the fleet, and this vehicle is one of the vehicles in the fleet. Based on the collaborative database, the location points of each identified vehicle are rendered on a pre-loaded area map. Since all vehicles in the fleet are configured with the same synchronization word, and data packets are sent via one-way broadcast within a specific communication channel, collaborative vehicle positioning can be achieved not only in areas without cellular network coverage but also through instantaneous capture and parsing of data packets based on the synchronization word, thereby reducing positioning latency. Therefore, this system can solve the problem of high positioning latency in fleet collaborative positioning in areas without cellular network coverage, achieving the effect of reducing positioning latency and improving positioning efficiency.

[0034] Optionally, each vehicle in the fleet can be configured with the same preset synchronization word and continuously transmit data packets containing location information in a one-way broadcast mode within a preset communication channel to construct a decentralized, dependency-free, high-concurrency real-time collaborative positioning communication network. Here, the preset synchronization word refers to a set of fixed-length bit sequences pre-configured and fixed in all communication nodes, located at the beginning of the data packet, which 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 fixed by firmware before deployment, and the transmitters and receivers of all vehicles can be configured with the same preset synchronization word.

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

[0036] Optionally, the vehicle's transmitter module is configured to send data packets in a one-way broadcast manner within a preset communication channel. One-way broadcast refers to a communication mode where data transmission is initiated independently by the transmitter, without requiring a response, acknowledgment, retransmission, or the establishment of any connection at the receiving end. The broadcast process is a one-way transmission mode; that is, the transmitter module only performs data transmission, does not listen to any wireless signals, does not wait for reception acknowledgment, does not need to establish a connection, and does not require relay forwarding.

[0037] Optionally, the vehicle's receiver module can be installed inside the vehicle and receive wireless radio frequency signals broadcast from the transmitter modules of other vehicles in the convoy via an antenna, and output a demodulated digital serial data stream.

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

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

[0040] In this embodiment, when a vehicle receives a first data packet sent by any target vehicle from a preset communication channel, the physical layer frame header of the data packet can be scanned byte by byte to extract the synchronization word located at the beginning of the frame. The extracted synchronization word in the first data packet is then compared bit by bit with the preset synchronization word stored locally.

[0041] 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 a message through a specific communication channel, thus satisfying the protocol admission conditions. Under this premise, the subsequent data frame parsing process can be initiated.

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

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

[0044] Optionally, the first data frame in the first data packet can be parsed to obtain the vehicle identifier and location data of the target 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 target 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 target vehicle.

[0045] Optionally, the parsing process can be executed in real time at the receiving end in an interrupt-driven manner, without relying on external clock synchronization or network protocol stack, without performing frame reordering or retransmission requests, and only based on synchronization word matching and CRC check results to decide whether to accept data frames.

[0046] Through the above process, each vehicle can realize a point-to-multipoint data broadcast topology in a peer-to-peer manner. Each vehicle, as a node, is equipped with a corresponding communication unit that can undertake the functions of transmission and reception. The transmission frame of any node can be received and parsed by all other nodes in the area, realizing mutual perception and state synchronization. There is no master-slave relationship between nodes, and no central control node is required.

[0047] In this embodiment, there may be no central node in the fleet, the data stream may not pass through any intermediate forwarding device, and the failure or offline status of any node will not affect the communication capabilities and positioning functions of other nodes, so as to realize decentralized P2MP networking.

[0048] Optionally, the parsed vehicle identification and location data can be written to a local collaborative database to update the position and trajectory of the corresponding vehicle node in the map engine.

[0049] In this embodiment, after obtaining the target vehicle's vehicle identifier and location data, the target vehicle's location data can be written to a local collaborative database based on the vehicle identifier. The collaborative database can be a structured data table deployed in the vehicle's storage system, used to store the location data of each of all identified vehicles. It can be organized in key-value pair format, with the vehicle identifier as the index field. Each record entry can include longitude coordinates, latitude coordinates, altitude, timestamp, and data validity flags. When the target vehicle identifier is successfully parsed for the first time, a corresponding record can be dynamically created in the collaborative database; if the identifier already exists, its original location data and timestamp can be overwritten to ensure that each record in the database always reflects the latest location status of the corresponding vehicle. Here, "all identified vehicles" refers to vehicles in the convoy that have been identified by this vehicle. This can refer to other convoy member vehicles within the current communication range whose data packets have been successfully received by this vehicle, whose synchronization words have been matched, whose CRC checks have passed, and whose location data decoding has been completed.

[0050] Optionally, based on a collaborative database, the location points of each identified vehicle can be rendered on a pre-loaded regional map of this vehicle.

[0051] Optionally, the aforementioned regional map can be an offline map, a map used and modified in an offline environment, or a cached online map. This embodiment does not impose any limitations on this.

[0052] Optionally, based on the location data of all identified vehicles stored in the collaborative database, the vehicle's graphics processing unit can call a pre-loaded regional map engine to map the location points of each identified vehicle to a map plane coordinate system according to the longitude and latitude values ​​of each record in the collaborative database, and visualize them using geometric symbols (such as circles, triangles, or numbered markers). Simultaneously, motion path lines can be drawn based on the displacement trajectories of each vehicle's continuous timestamps. The color and width of the path lines are dynamically adjusted according to the vehicle's dynamic state (such as speed and acceleration) to enhance situational awareness.

[0053] Optionally, the vehicle's own positioning data can also be mapped and rendered in the central area of ​​the map as a reference point. Here, all rendering operations are performed locally, without relying on any network connection, cloud service, or third-party map interface. The map update frequency can be synchronized with the positioning data reception frequency to ensure the real-time and consistent location points in dynamic scenarios.

[0054] Since all vehicles have identical synchronization words, communication channels, and broadcast parameters, data packets sent by any vehicle can be captured and parsed by the receiving modules of all other vehicles in the area. This mechanism does not rely on a central node, network routing, address allocation, or handshake protocol, and enables point-to-multipoint broadcast communication.

[0055] Optionally, data frames broadcast simultaneously by multiple vehicles can be received by the receiving vehicle after propagating through the air, forming a continuous mixed data stream. Since all vehicles use the same synchronization word, the receiving module does not distinguish the sending source, and all data frames can be received and serially output in chronological order, forming a mixed frame sequence containing data from multiple target vehicles.

[0056] In the embodiments of this application, each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. When a first data packet of a target vehicle is received from the preset communication channel, the synchronization word in the first data packet is extracted. In response to the synchronization word in the first data packet matching the preset synchronization word, the first data frame in the first data packet is parsed to obtain the vehicle identifier and positioning data of the target vehicle. When the vehicle identifier and positioning data of the target vehicle are obtained, the positioning data of the target vehicle is updated to the local collaborative database of the vehicle based on the vehicle identifier. 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, and this vehicle is a vehicle in the fleet. Based on the collaborative database, the location points of each identified vehicle are rendered on the area map preloaded by this vehicle. This can solve the problem of high positioning latency in fleet collaborative positioning in areas without cellular network coverage, and achieve the effect of reducing positioning latency and improving positioning efficiency.

[0057] In an exemplary embodiment, in response to a synchronization word in a first data packet matching a preset synchronization word, parsing a first data frame in the first data packet includes:

[0058] In response to the synchronization word in the first data packet matching the preset synchronization word, the first check value is extracted from the first data frame;

[0059] A second check value is generated based on the payload portion of the first data frame;

[0060] If the first and second check values ​​match, the vehicle identification number and the target vehicle's location data are parsed from the payload portion.

[0061] In this embodiment, in response to the synchronization word in the first data packet matching a preset synchronization word, the first data frame in the first data packet can be verified.

[0062] like Figure 3As shown, in a network-free digital cooperative system, data can go through the following steps: collected by a GPS module, transmitted via bus to the vehicle's processing unit for encoding (e.g., DBU encoding), and then broadcast via a transmitter. Correspondingly, the processing units of other vehicles receiving the broadcast decode the data (e.g., HMI decoding). In the wireless transmission step, the data is highly susceptible to adverse environmental conditions and channel interference; therefore, data frames need to be inspected.

[0063] Optionally, the first data frame may include a frame header, a payload, and an additional check field. In response to a synchronization word in the first data packet matching 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.

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

[0065] 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 and location data of the target vehicle from the payload portion.

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

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

[0068] In an exemplary embodiment, in response to a synchronization word in a first data packet matching a preset synchronization word, parsing a first data frame in the first data packet includes:

[0069] In response to the synchronization word in the first data packet matching the preset synchronization word, the vehicle identifier of the target vehicle is extracted from the vehicle identifier field of the first data frame, and the initial positioning data is extracted from the positioning data field of the first data frame.

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

[0071] In this embodiment, in response to the synchronization word in the first data packet matching the preset synchronization word, the vehicle identifier of the target 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.

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

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

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

[0075] Optionally, if the transmitting module uses other compression algorithms, the receiving module of this vehicle can perform reverse decoding using corresponding reverse decoding algorithms to restore the initial positioning data to the positioning data of the target vehicle.

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

[0077] In an exemplary embodiment, each vehicle is equipped with an on-board data processing terminal and processing components, wherein the extraction of synchronization words from the first data packet, parsing of the first data frame, updating of the target vehicle's positioning data to the collaborative database, and rendering of the location points of each identified vehicle on the regional map are performed by the processing components of the vehicle itself.

[0078] The above methods also include:

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

[0080] 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 second data packet to be sent by the vehicle.

[0081] The second data packet is sent via a one-way broadcast through the vehicle's onboard data processing terminal within a preset communication channel.

[0082] In this embodiment, each vehicle can be equipped with an onboard data processing terminal and processing unit, which can be independent hardware units that interact with each other via the UART / CRSF protocol. The vehicle data processing terminal can perform data acquisition, encoding, and encapsulation. The vehicle's processing unit can perform tasks such as extracting synchronization words from the first data packet, parsing the first data frame, updating the target vehicle's location data 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, possessing independent storage, computing, and graphics rendering capabilities, and is responsible for receiving, verifying, decoding, and visualizing telemetry data from other vehicles.

[0083] 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 4 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.

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

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

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

[0087] Optionally, the vehicle's onboard data processing terminal can encapsulate the compressed positioning data into a second 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 second data packet.

[0088] Optionally, the second 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 second 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.

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

[0090] 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;

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

[0092] 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;

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

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

[0095] 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).

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

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

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

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

[0100] In response to the synchronization word in the first data packet matching the preset synchronization word, the first data frame in the first data packet is parsed, including: when the target vehicle is a first type of vehicle, in response to the synchronization word in the first data packet matching the preset synchronization word, the vehicle identifier of the target vehicle, the positioning data of the target vehicle, and the parameter values ​​of the vehicle status parameters of the target vehicle are parsed from the first data frame.

[0101] After parsing the first data frame in the first data packet, the method further includes: updating the parameter values ​​of the vehicle status parameters of the target vehicle to the collaborative database based on the vehicle identifier of the target vehicle; and updating the displayed vehicle status of the target vehicle on the regional map based on the collaborative database.

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

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

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

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

[0106] Optionally, based on the vehicle identifier of the target 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.

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

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

[0109] In this embodiment, without changing the decentralized P2MP architecture, the above-mentioned vehicle cooperative positioning 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 training 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 can achieve real-time reference and simulation learning of driving trajectories. This not only supports basic positioning cooperation, 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.

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

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

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

[0113] The above methods also include:

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

[0115] The vehicle's location data and vehicle status parameter values ​​are encapsulated into a third data packet to be sent by the vehicle.

[0116] The third data packet is sent in a one-way broadcast manner within the preset communication channel.

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

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

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

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

[0121] Optionally, after encapsulation, a third data packet can be sent in a one-way broadcast manner within a preset communication channel. This can be achieved by injecting the third 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 achieving delay-free, decentralized, and fully distributed sharing of the status of first-class vehicles.

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

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

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

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

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

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

[0128] 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 delay meets system requirements and reduce positioning delay.

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

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

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

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

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

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

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

[0136] The following describes the vehicle cooperative positioning method within a fleet in this application embodiment 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 positioning data). Figure 5 This is a flowchart illustrating the vehicle cooperative localization method within a fleet in this optional example, as shown below. Figure 5 As shown, the process of the vehicle cooperative localization method within this fleet may include the following steps:

[0137] Step S502: The vehicle MCU starts running.

[0138] Step S504: High-frequency acquisition of GPS coordinates.

[0139] Step S506: Acquire CAN / other bus data.

[0140] Step S508, 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).

[0141] Step S510, 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).

[0142] Step S512, ELRS RX module receives.

[0143] Step S514, verification and decoding.

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

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

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

[0147] Step S522, 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.

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

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

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

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

[0152] According to another aspect of the embodiments of this application, a vehicle cooperative positioning device within a fleet is also provided. This vehicle cooperative positioning device within a fleet can be used to implement the vehicle cooperative positioning 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.

[0153] Similar to the previous embodiments, each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. Each vehicle's data packet includes the 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. Figure 6 This is a structural block diagram of an optional vehicle cooperative positioning device within a fleet according to an embodiment of this application, such as... Figure 6 As shown, the vehicle cooperative positioning device within the fleet includes:

[0154] Processing unit 602 is configured to: upon receiving a first data packet from a target vehicle via a preset communication channel; extract a synchronization word from the first data packet; parse a first data frame in the first data packet to obtain the vehicle identifier and location data of the target vehicle; update the location data of the target vehicle to the local collaborative database based on the vehicle identifier, wherein the collaborative database stores the location data of each identified vehicle among all identified vehicles, all identified vehicles being those identified by this vehicle in the convoy, and this vehicle being the vehicle in the convoy; and render the location points of each identified vehicle on a pre-loaded area map of this vehicle based on the collaborative database.

[0155] Display component 604 is used to display a regional map and mark the location points of each identified vehicle rendered on the displayed regional map.

[0156] It should be noted that the processing unit 602 in this embodiment can be used to perform the above steps S202 to S208, and those already described will not be repeated.

[0157] According to the embodiments provided in this application, each vehicle in the fleet is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. When a first data packet of a target vehicle is received from the preset communication channel, the synchronization word in the first data packet is extracted. In response to the synchronization word in the first data packet matching the preset synchronization word, the first data frame in the first data packet is parsed to obtain the vehicle identifier and positioning data of the target vehicle. When the vehicle identifier and positioning data of the target vehicle are obtained, the positioning data of the target vehicle is updated to the local collaborative database of the vehicle based on the vehicle identifier. 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, and this vehicle is a vehicle in the fleet. Based on the collaborative database, the location points of each identified vehicle are rendered on the area map preloaded by this vehicle. This can solve the problem of high positioning latency in fleet collaborative positioning in areas without cellular network coverage, and achieve the effect of reducing positioning latency and improving positioning efficiency.

[0158] In one exemplary embodiment, the vehicle cooperative positioning 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.

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

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

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

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

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

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

[0165] 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 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, 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.

[0166] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which performs various appropriate actions and processes based on programs stored in ROM 702 or loaded into RAM 703 from storage section 708. Random access memory 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

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

[0168] 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 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions defined in the system of this application.

[0169] It should be noted that, Figure 7 The computer system 700 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.

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

[0171] 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 cooperative vehicle positioning within a fleet, characterized in that, Each vehicle in the convoy is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. The method includes: Upon receiving a first data packet from the target vehicle via the preset communication channel, the synchronization word in the first data packet is extracted. In response to the synchronization word in the first data packet matching the preset synchronization word, the first data frame in the first data packet is parsed to obtain the vehicle identifier of the target vehicle and the location data of the target vehicle; Upon obtaining the vehicle identifier and location data of the target vehicle, the location data of the target vehicle is updated to the local collaborative database of this vehicle based on the vehicle identifier. The collaborative database is used to store the location data of each of all identified vehicles in the fleet. All identified vehicles are vehicles in the fleet that have been identified by this vehicle. This vehicle is one of the vehicles in the fleet. Based on the collaborative database, the location points of each identified vehicle are rendered on the pre-loaded regional map of the vehicle.

2. The method according to claim 1, characterized in that, The step of parsing the first data frame in the first data packet in response to the synchronization word in the first data packet matching the preset synchronization word includes: In response to the synchronization word in the first data packet matching the preset synchronization word, a first check value is extracted from the first data frame; A second check value is generated based on the payload portion of the first data frame; If the first check value and the second check value match, the vehicle identifier and the location data of the target vehicle are parsed from the payload portion.

3. The method according to claim 1, characterized in that, The step of parsing the first data frame in the first data packet in response to the synchronization word in the first data packet matching the preset synchronization word includes: In response to the synchronization word in the first data packet matching the preset synchronization word, the vehicle identifier of the target vehicle is extracted from the vehicle identifier field of the first data frame, and the initial positioning data is extracted from the positioning data field of the first data frame. The initial positioning data is subjected to reverse localization decoding to restore the initial positioning data to the positioning data of the target vehicle.

4. The method according to claim 1, characterized in that, Each vehicle is equipped with an on-board data processing terminal and processing components. The processing components of the vehicle itself are responsible for extracting the synchronization word from the first data packet, parsing the first data frame, updating the positioning data of the target vehicle to the collaborative database, and rendering the location points of each identified vehicle on the regional map. 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 second data packet to be sent by the vehicle. The second data packet is transmitted via a one-way broadcast through the vehicle's onboard data processing terminal within the preset communication channel.

5. The method according to claim 1, 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 each identified vehicle on the pre-loaded regional 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.

6. The method according to claim 1, 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 first data frame in the first data packet in response to the synchronization word in the first data packet matching the preset synchronization word includes: when the target vehicle is the first type of vehicle, in response to the synchronization word in the first data packet matching the preset synchronization word, parsing the vehicle identifier of the target vehicle, the positioning data of the target vehicle, and the parameter values ​​of the vehicle status parameters of the target vehicle from the first data frame. After parsing the first data frame in the first data packet, the method further includes: updating the parameter value of the vehicle status parameter of the target vehicle to the collaborative database based on the vehicle identifier of the target vehicle; and updating the displayed vehicle status of the target vehicle on the regional map based on the collaborative database.

7. The method according to claim 1, 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 a third data packet to be sent by the vehicle. The third data packet is sent in a one-way broadcast manner within the preset communication channel.

8. The method according to any one of claims 1 to 7, characterized in that, The CRSF telemetry frame has a frame type of 0x10; the preset communication channel is a 2.4GHz wireless communication frequency band; the transmission rate of the CRSF telemetry frame is not less than 500 Hz and the frame interval is not more than 2 milliseconds.

9. The method according to any one of claims 1 to 7, 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.

10. A vehicle cooperative positioning device within a fleet, characterized in that, Each vehicle in the convoy is equipped with a preset synchronization word. Each vehicle is used to send data packets in a one-way broadcast manner within a preset communication channel. The data packets of each vehicle include the preset synchronization word and a data frame for carrying positioning data. The data frame in the data packets of each vehicle is a CRSF telemetry frame. The vehicle cooperative positioning device includes: A processing unit is configured to: upon receiving a first data packet from a target vehicle via a preset communication channel; extract a synchronization word from the first data packet; parse a first data frame in the first data packet in response to a match between the synchronization word in the first data packet and the preset synchronization word, to obtain the vehicle identifier and location data of the target vehicle; update the location data of the target vehicle to a local collaborative database based on the vehicle identifier, wherein the collaborative database stores the location data of each of all identified vehicles in the fleet, wherein all identified vehicles are all vehicles identified by the vehicle in the fleet, and the vehicle in the fleet is the vehicle where the vehicle collaborative positioning device is located; and render the location points of each identified vehicle on a pre-loaded area map of the vehicle based on the collaborative database. A display component is used to display the area map and mark the location points of each identified vehicle rendered on the displayed area map.

11. The vehicle cooperative positioning device according to claim 10, characterized in that, The vehicle cooperative positioning device further includes a positioning antenna and a wireless communication antenna, which are mounted via a mast and are higher than the vehicle body structure.

12. The vehicle cooperative positioning device according to claim 11, characterized in that, The vehicle cooperative positioning device, except for the positioning antenna, the wireless communication antenna, and the mast, is encapsulated in the same housing.

13. 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 9.

14. 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 9.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

Images