A communication middleware for heterogeneous networks

Abstract

The present invention provides a communication middleware for heterogeneous networks, belonging to the field of distributed communication technology, including a proxy module arranged on each drone in a drone cluster, the proxy modules on different drones realize inter-machine communication through a data distribution service NetDDS; the proxy module is used to receive a request sent by a communication entity of a drone in the drone cluster, establish a tunnel of a corresponding topic according to the request, so that the request is transmitted to the proxy module on the target drone through the tunnel via the data distribution service NetDDS, and the request is sent to the communication entity of the target drone through the proxy module on the target drone. By adopting such a proxy module and tunnel mechanism, the present invention effectively solves the challenge of inter-machine communication and provides an efficient and reliable communication environment for drone cluster applications.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed communication, and in particular relates to a communication middleware oriented to heterogeneous networks. Background Art

[0002] Over the past few decades, with the rapid development of drone technology, drones have become an important tool in military operations. However, the traditional single drone combat mode has some limitations, including limited maneuverability, perception capabilities, and firepower strike range. In order to overcome these limitations and improve combat effectiveness, drone swarm combat technology has emerged. Drone swarms can rely on decentralized and distributed organizational methods to form unique combat advantages that single combat platforms do not have, such as economic advantages, quantitative advantages, coordination and intelligence advantages, and speed advantages. It is considered to be one of the most promising combat styles in future intelligent warfare.

[0003] When drone swarms perform tasks, they need to transmit and share a large amount of data in real time, including task instructions, sensor data, target information, etc. At the same time, the drone network needs to be managed and coordinated, including network topology management, routing selection, and link load balancing, and to ensure stable and reliable information interaction, as well as the real-time and security of information interaction.

[0004] In current drone cluster applications, intra-machine communication and inter-machine communication belong to heterogeneous networks. Forwarding intra-machine data to other drones requires developers to repeat a lot of work. At the same time, the intra-machine communication channel belongs to a wired channel, which can provide high bandwidth and reliability guarantee, while the inter-machine communication channel belongs to a wireless channel, which has the characteristics of low bandwidth and no reliability guarantee. There is currently a problem that a set of data distribution services cannot meet the needs of intra-machine and inter-machine communication at the same time. Summary of the invention

[0005] In order to solve the problem that a lot of work needs to be repeated when nodes communicate with each other across machines, and that a set of data distribution services cannot simultaneously meet the needs of intra-machine and inter-machine communication, and to support the development of drone cluster applications, the present invention provides a communication middleware for heterogeneous networks.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] A communication middleware for heterogeneous networks, including a proxy module set on each drone in a drone cluster, and the proxy modules on different drones realize inter-machine communication through a data distribution service NetDDS;

[0008] The proxy module is used to receive requests sent by the communication entity of the drone belonging to the drone cluster, establish a tunnel for the corresponding topic according to the request, so that the request is transmitted to the proxy module on the target drone through the tunnel via the data distribution service NetDDS, and send the request to the communication entity of the target drone through the proxy module on the target drone.

[0009] Preferably, the proxy module communicates with the corresponding communication entity via the data distribution service FastDDS inside the drone.

[0010] Preferably, the communication entities include a publisher, a subscriber, a server and a client.

[0011] Preferably, the proxy module starts a server of a specific topic FastDDS through a remote procedure call on FastDDS, and listens to the proxy request initiated by the unified interface; after receiving the proxy request, in the initial creation entity request, for the publisher, an exit RTPS tunnel is created; for the subscriber, an entry RTPS tunnel is created; for the client, an exit request tunnel and an entry response tunnel are created; for the server, an entry request tunnel and an exit response tunnel are created.

[0012] Preferably, the proxy module is further used to increase the reference count of the corresponding tunnel by 1 in a subsequent entity creation request; and to decrease the reference count of the corresponding tunnel by 1 during entity destruction. If the reference count is 0, the tunnel is destroyed.

[0013] Preferably, the proxy module is also used to complete the forwarding logic of the publish-subscribe related tunnels and provide a unified interface for creating publishers and subscribers; the forwarding logic of the publish-subscribe related tunnels specifically includes the forwarding logic of the egress publishing tunnel OutRTPSTunnel and the forwarding logic of the ingress subscription tunnel InRTPSTunnel;

[0014] The forwarding logic of the egress publishing tunnel OutRTPSTunnel is as follows:

[0015] Register the FastDDS subscriber new data arrival event in the constructor;

[0016] After the event is triggered, the serialized data is taken into the buffer; it is determined whether the data comes from the entry tunnel of the same topic. If so, the data is ignored; if not, the NetDDS publisher will publish the byte stream in the buffer;

[0017] The forwarding logic of the ingress subscription tunnel InRTPSTunnel is:

[0018] Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer;

[0019] After obtaining it, the publisher of FastDDS publishes the byte stream.

[0020] Preferably, the proxy module is also used to adopt a remote procedure call mechanism based on data distribution service, and use the publish-subscribe mode to realize the request and response communication between the client and the server, specifically including:

[0021] Each remote call request contains a globally unique identifier GUID, which is used to identify which specific client the request comes from; each request also contains a serial number, which is used to uniquely identify the specific request so that the client can correctly match the received response; after receiving the request, the server needs to return the request header intact in the response, and the returned content includes the GUID and serial number; the client filters out requests that are not initiated by itself based on the GUID, and obtains the response data corresponding to the request based on the serial number.

[0022] Preferably, the proxy module is also used to complete the forwarding logic of the request-response related tunnels, and provide a unified interface for creating a client and a server; the forwarding logic of the request-response related tunnels specifically includes the forwarding logic of the egress request tunnel OutRequestTunnel and the forwarding logic of the ingress response tunnel InResponseTunnel;

[0023] The forwarding logic of the egress request tunnel OutRequestTunnel is as follows:

[0024] Register the FastDDS subscriber new data arrival event in the constructor;

[0025] After the event is triggered, new data is taken out to the forwarding buffer;

[0026] Use the GUID filter to determine whether the data comes from the same topic entry tunnel. If so, ignore it. If not, take out the sequence number on the sample_identity of the data and the GUID on the related_sample_identity. Use the sequence number as the key to take out the GUID and sequence number on the value from the mapping table and serialize them to the end of the buffer.

[0027] Byte stream of the buffer published by the NetDDS publisher;

[0028] The forwarding logic of the ingress response tunnel InResponseTunnel is as follows:

[0029] Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer;

[0030] Take out the GUID and serial number from the end of the buffer, and then the FastDDS publisher publishes the data to obtain the serial number of this publication. Use the serial number as the key and the previously taken GUID and serial number as the value to store them in the mapping table, and load the GUID and serial number to related_sample_identity.

[0031] The ingress request tunnel and the egress response tunnel are related to the server. A pair of tunnels under the same service name need to share a sequence number mapping table and correctly complete the forwarding of the sequence number according to the mapping table.

[0032] Preferably, the proxy module is also used to control the traffic flowing out of a drone exit tunnel to the outside of the drone to flow into the drone entrance tunnel of the same topic, specifically:

[0033] When creating an inlet tunnel, the GUID of the publisher on FastDDS is taken and stored in the GUID filter; when forwarding data on the egress tunnel, the GUID of the data publisher is taken. If there is an inlet tunnel with the same topic and the GUID matches, the data will not be forwarded, otherwise it will be forwarded.

[0034] The communication middleware for heterogeneous networks provided by the present invention has the following beneficial effects:

[0035] The present invention sets a proxy module on each drone in the drone cluster, and the proxy modules on different drones realize inter-machine communication through the data distribution service NetDDS, and the communication between different drones in the drone cluster can be realized through the data distribution service NetDDS. At the same time, the proxy module receives the request sent by the communication entity of the drone in the drone cluster, establishes a tunnel of the corresponding topic according to the request, so that the request is transmitted to the proxy module on the target drone through the tunnel via the data distribution service NetDDS, and the request is sent to the communication entity of the target drone through the proxy module on the target drone, and the intra-machine and inter-machine communication is completed through the data distribution service NetDDS and the proxy module. By adopting this proxy module and tunnel mechanism, the challenge of inter-machine communication is effectively solved, and an efficient and reliable communication environment is provided for drone cluster applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiment of the present invention and its design scheme, the following briefly introduces the drawings required for this embodiment. The drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0037] Figure 1 This is a logical block diagram of a communication middleware for heterogeneous networks according to Embodiment 1 of the present invention;

[0038] Figure 2 The process of publishing data from the publisher on drone A to the subscriber on drone B;

[0039] Figure 3 The process of initiating a remote procedure call for the client on drone A;

[0040] Figure 4 It is the workflow diagram of the agent module;

[0041] Figure 5 This is a class diagram of a tunnel, where: Figure 5 (A) is the exit tunnel class diagram. Figure 5 (B) is the entrance tunnel class diagram. DETAILED DESCRIPTION

[0042] In order to enable those skilled in the art to better understand the technical solution of the present invention and implement it, the present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the scope of protection of the present invention.

[0043] Example 1

[0044] The data distribution service adopts a data-centric publish-subscribe model, which can provide a high-performance, reliable, and real-time data transmission model suitable for complex real-time application scenarios such as drone clusters, industrial automation, and intelligent transportation. Based on this, the present invention proposes a communication middleware for heterogeneous networks, aiming to achieve efficient interconnection and intercommunication between drone clusters. The communication middleware has features specially designed for drone clusters, can effectively cope with communication challenges in heterogeneous network environments, and ensure the reliability of data transmission.

[0045] The overall idea of ​​the present invention is to build a proxy module, use a lightweight and configurable data distribution service NetDDS to achieve the goal of inter-machine communication, and provide a unified interface for publish-subscribe and request-response communication modes. In this solution, the upper-layer application calls a unified interface to create a FastDDS entity. The entity that needs to communicate sends a request to the proxy. The proxy establishes a tunnel for the corresponding topic based on the request, so that data can cross different networks through the tunnel, thereby realizing the interconnection between various entities. Figure 1 shown.

[0046] By adopting this proxy module and tunnel mechanism, the challenge of inter-machine communication is effectively solved, providing an efficient and reliable communication environment for drone cluster applications. At the same time, developers do not need to pay attention to the specific implementation of inter-machine communication, but only need to call the standard interface provided by the proxy, which simplifies the application development process.

[0047] Specifically, the present invention provides a communication middleware for heterogeneous networks, including a proxy module set on each drone in a drone cluster, and the proxy modules on different drones realize inter-machine communication through the data distribution service NetDDS. The proxy module is used to receive a request sent by a communication entity of a drone in the drone cluster, establish a tunnel of a corresponding topic according to the request, so that the request is transmitted to the proxy module on the target drone through the tunnel via the data distribution service NetDDS, and send the request to the communication entity of the target drone through the proxy module on the target drone. The communication middleware, the function of the proxy module is further described below.

[0048] (1) The proxy module implements the functions of sensing the existence of entities, creating or destroying tunnels, and maintaining GUID filters. The proxy module is responsible for managing tunnels. After the tunnel receives the data to be sent out, the operation logic of forwarding it to the machine is completed by the publish-subscribe adapter module.

[0049] Since the proxy also belongs to the application in the machine, the present invention notifies the proxy and transmits information through the FastDDS remote procedure call in the machine. When the proxy module is started, a server instance will be created on FastDDS to listen to the proxy request, thereby sensing the existence of the entity. When the upper-level application calls the unified interface to create (destroy) an entity, a client of the service will be created. The client sends a request to the proxy, and the request content includes the type of entity, topic name or service name, etc. After the proxy obtains the request, it creates a corresponding tunnel according to the type of entity. Data crosses different networks through the tunnel to achieve mutual communication between various DDS entities.

[0050] Specifically, the proxy module is used to complete the functions of the entities in the perception machine through remote procedure calls on FastDDS, and manage tunnels according to information such as the entity type, topic or service name.

[0051] The processing flow of the proxy module is as follows:

[0052] S101, the proxy module starts a FastDDS server with a specific topic to listen to the proxy request initiated by the unified interface.

[0053] S102. After receiving the proxy request, in the initial entity creation request, for the publisher, an egress RTPS tunnel is created; for the subscriber, an ingress RTPS tunnel is created; for the client, an egress request tunnel and an ingress response tunnel are created; for the server, an ingress request tunnel and an egress response tunnel are created. In the subsequent entity creation request, the reference count of the corresponding tunnel is increased by 1, that is, multiple entities with the same topic share one tunnel. This ensures that data is not repeated during inter-machine communication.

[0054] During the entity destruction process, the reference count of the corresponding tunnel is reduced by 1. If the reference count is 0, the tunnel is destroyed. The specific flow chart is as follows Figure 4 shown.

[0055] The proxy module needs to create a handle to NetDDS in order to create the corresponding entity on NetDDS when the tunnel is initialized. It needs to create a specific service name server of FastDDS in order to receive proxy requests when calling the unified interface. It needs to store relevant information of the egress tunnel and the ingress tunnel. It needs a GUID filter to avoid data loops. It needs a sequence number mapping table for the server tunnel to correctly forward the sequence number. The encapsulation of the proxy module is shown in Table 1.

[0056] Table 1 Encapsulation of the proxy module

[0057]

[0058] The request and response custom structures of the proxy service contain the entity type, topic name or service name, etc., as shown in Table 2.

[0059] Table 2 Request and response structures of proxy services

[0060]

[0061] The base class OutTunnel of the egress tunnel is used to forward egress traffic. The core data structure is a publisher on FastDDS and a subscriber on NetDDS. The specific encapsulation is shown in Table 3.

[0062] Table 3 Encapsulation of the egress tunnel base class

[0063]

[0064] The base class InTunnel of the ingress tunnel is used to receive ingress traffic. The core data structure is a subscriber on NetDDS and a publisher on FastDDS. The specific encapsulation is shown in Table 4.

[0065] Table 4 Encapsulation of the entry tunnel base class

[0066]

[0067] The subclasses of OutTunnel currently include OutRTPSTunnel, OutRequestTunnel, and OutResponseTunnel. OutRTPSTunnel is used for the traffic of the export publisher, OutRequestTunnel is used for the traffic of the export request, and OutResponseTunnel is used for the traffic of the export response.

[0068] The subclasses of InTunnel currently include InRTPSTunnel, InRequestTunnel, and InResponseTunnel. InRTPSTunnel is used for ingress subscriber traffic, InRequestTunnel is used for ingress request traffic, and InResponseTunnel is used for ingress response traffic. The class diagram of the tunnel is as follows Figure 5 As shown, Figure 5 (A) is the exit tunnel class diagram. Figure 5 (B) is the entrance tunnel class diagram.

[0069] (2) The proxy module provides the adaption function of publishing and subscribing

[0070] Consider the following usage scenario: Drone A and Drone B both start the proxy software, Drone A creates a publisher through the socket, and Drone B creates a subscriber through the socket.

[0071] In the present invention, the proxy software on drone A obtains the request of the publisher on the same drone and automatically creates an exit tunnel corresponding to the publisher. Similarly, the proxy software on drone B obtains the request of the subscriber on the same drone and automatically creates an entry tunnel corresponding to the subscriber. The exit tunnel is composed of the subscriber on FastDDS and the publisher on NetDDS, and the entry tunnel is composed of the subscriber on NetDDS and the publisher on FastDDS.

[0072] When the publisher on drone A publishes data, the data is transmitted through the tunnel in the heterogeneous network, thus realizing the communication between the publisher on drone A and the subscriber on drone B. The data flow in this scenario is as follows: Figure 2 shown.

[0073] Specifically, the adaptation of publish and subscribe includes the following two parts: completing the forwarding logic of publish and subscribe related tunnels; providing a unified interface for creating publishers and subscribers.

[0074] First, the forwarding logic of the publish-subscribe tunnel

[0075] The forwarding logic of the egress publishing tunnel OutRTPSTunnel is as follows:

[0076] 1. Register the FastDDS subscriber new data arrival event in the constructor.

[0077] 2. After the event is triggered, the serialized data is taken into the buffer. It is determined whether the data comes from the entry tunnel of the same topic. If so, the data is ignored; if not, the NetDDS publisher will publish the byte stream in the buffer.

[0078] The forwarding logic of the ingress subscription tunnel InRTPSTunnel is:

[0079] 1. Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer.

[0080] 2. After obtaining it, the publisher of FastDDS publishes the byte stream.

[0081] Second, provide a unified interface for creating publishers and subscribers

[0082] The unified publish-subscribe interface is implemented by filling the structure according to the content defined in Table 2. Taking the publisher as an example, entity_type is PUBLISHER, the constructor is_create is true, the destructor is false, topic_or_service_or_action_name is the topic passed in by the user, and the proxy service is judged to exist. If it exists, a proxy request is sent, and if it does not exist, the proxy of the entity fails. Then the parameters are forwarded to the FastDDS interface to create publishers and subscribers.

[0083] The proxy's publish-subscribe class inherits from the middleware publish-subscribe class. The specific creation interface is shown in Table 5.

[0084] Users create publishers and subscribers through a unified interface to complete publish-subscribe communication within and between machines without having to pay attention to the interaction with the agent.

[0085] (3) The proxy module provides remote procedure call adaptation function

[0086] The present invention adopts a remote procedure call mechanism based on data distribution service, and utilizes the publish-subscribe mode to realize the request and response communication between the client and the server. The client includes a request publisher and a response subscriber. The request publisher is responsible for publishing the remote procedure call request, and the response subscriber is used to receive the response returned by the server. Correspondingly, the server has a request subscriber and a response publisher. The request subscriber subscribes to and receives the remote call request published by the client, and the response publisher is responsible for publishing the response data to the corresponding client.

[0087] Table 5: Create interface for publish-subscribe classes on the proxy

[0088]

[0089] In order to accurately identify the source of the request and the corresponding relationship between the response, the invention designs the following mechanism:

[0090] Each remote call request contains a globally unique identifier GUID, which is used to identify which specific client the request comes from. Each request also contains a sequence number, which is used to uniquely identify the specific request so that the client can correctly match the received response. After receiving the request, the server needs to return the request header intact in the response, and the returned content includes the GUID and sequence number. The client filters out requests that are not initiated by itself based on the GUID, and obtains the response data corresponding to the request based on the sequence number.

[0091] Consider the following usage scenario: Drone A and Drone B both start the proxy software, Drone A creates a client through the socket, and Drone B creates a server through the socket.

[0092] In the present invention, the proxy software on drone A obtains the request of the client on the same drone, and automatically creates a tunnel for the exit request and a tunnel for the entry response. Similarly, the proxy software on drone B obtains the request of the server on the same drone, and automatically creates a tunnel for the entry request and a tunnel for the exit response. The exit tunnel is composed of the subscriber on FastDDS and the publisher on NetDDS, while the entry tunnel is composed of the subscriber on NetDDS and the publisher on FastDDS.

[0093] The client on drone A initiates a remote procedure call, and the data flows as follows Figure 3 shown.

[0094] Specifically, the remote procedure call adaptation module also includes the following two parts: completing the forwarding logic of the request-response related tunnel; and providing a unified interface for creating the client and the server.

[0095] First, request response tunnel forwarding logic

[0096] The egress request tunnel and the ingress reply tunnel are associated with the client.

[0097] The forwarding logic of the egress request tunnel OutRequestTunnel is as follows:

[0098] 1. Register the FastDDS subscriber new data arrival event in the constructor.

[0099] 2. After the event is triggered, take out the new data to the forwarding buffer.

[0100] 3. Use the GUID filter to determine whether the data comes from the same topic entry tunnel. If so, ignore it. If not, take out the sequence number on the sample_identity of the data and the GUID on the related_sample_identity. Use the sequence number as the key to take out the GUID and sequence number on the value from the mapping table and serialize them to the end of the buffer.

[0101] 4. The byte stream of the buffer is published by the NetDDS publisher.

[0102] The forwarding logic of the ingress response tunnel InResponseTunnel is as follows:

[0103] 1. Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer.

[0104] 2. Take out the GUID and serial number from the end of the buffer, and then the FastDDS publisher publishes the data to obtain the serial number of this publication. Use the serial number as the key and the previously taken out GUID and serial number as the value, store them in the mapping table, and load the GUID and serial number to related_sample_identity.

[0105] The ingress request tunnel and the egress response tunnel are related to the server. A pair of tunnels under the same service name need to share a sequence number mapping table and correctly complete the forwarding of the sequence number according to the mapping table.

[0106] Second, provide a unified interface for creating clients and servers

[0107] Fill the structure according to the content defined in Table 2. Taking the client as an example, entity_type is CLIENT, constructor is_create is true, destructor is_create is false, topic_or_service_or_action_name is the service_name passed in by the user, and determine whether the proxy service exists. If it exists, send a proxy request. If it does not exist, the proxy of the entity fails. Then forward the parameters to the FastDDS interface to create a server client.

[0108] The client and server classes of the proxy inherit from the client and server classes of the middleware. The specific creation interface is shown in Table 6.

[0109] Users create clients and servers through a unified interface to complete request-response mode communications within and between machines without having to worry about interactions with proxies.

[0110] Table 6 Creation interface of client and server classes on the proxy

[0111]

[0112] (4) The proxy module provides the function of eliminating data loops on the proxy.

[0113] If a loop occurs in the tunnel created by the proxy, the data will be replayed repeatedly in the tunnel. To avoid this situation, the proxy forwarding traffic must meet the following two constraints.

[0114] 1. Traffic flowing out of a drone’s exit tunnel to the outside of the drone should not flow into the drone’s entry tunnel of the same topic.

[0115] 2. Traffic flowing into a drone from outside the drone should no longer flow out through the exit tunnel of the same topic of the drone.

[0116] To meet constraint 1, the present invention modifies NetDDS and provides a version that supports proxy mode. In proxy mode, subscribers to a topic on NetDDS will ignore data published by publishers of the same topic on the same machine. To meet constraint 2, the proxy adopts a strategy for controlling traffic forwarding based on GUID. Each entity of FastDDS can be distinguished by GUID. When creating an inlet tunnel, the GUID of the publisher of the inlet tunnel FastDDS is saved. When forwarding a message in the outlet tunnel, the GUID of the sender of the message is obtained and compared with the GUID of the publisher on the inlet tunnel. If they match, they are not forwarded. If they do not match, they are forwarded. Constraint 2 is thus met.

[0117] Specifically, the elimination of data loops on the proxy includes:

[0118] 1. NetDDS Proxy Mode

[0119] The NetDDS proxy mode is used to satisfy constraint one, that is, the traffic flowing out of a drone’s exit tunnel to the outside of the drone should not flow into the drone’s entry tunnel of the same topic.

[0120] The implementation principle of NetDDS proxy mode is: set the proxy mode Boolean value. During the topic synchronization process, if the proxy mode is started and the IP address is the same, the subscriber and publisher will not establish a connection relationship, and the subscriber of the data published by the subsequent publisher will not be able to send or receive data.

[0121] GUID Filter

[0122] The GUID filter is used to satisfy constraint 2, which states that traffic flowing into a drone from outside the drone should not flow out of the drone’s egress tunnel of the same topic.

[0123] When creating an inlet tunnel, the GUID of the publisher on FastDDS is taken and stored in the GUID filter. When forwarding data on the egress tunnel, the GUID of the publisher of the data is taken. If there is an inlet tunnel with the same topic and the GUID matches, the data will not be forwarded, otherwise it will be forwarded.

[0124] The proxy module of the present invention can sense the existence of inter-machine entities and manage tunnels. The publish-subscribe adaptation function provides users with an interface for creating publish-subscribe entities, and provides the implementation of tunnel publish-subscribe related data forwarding operations. The remote procedure call adaptation function provides users with an interface for creating remote procedure call entities, and provides the implementation of tunnel request-response related data forwarding operations. The data loop elimination function on the proxy avoids the data replay problem caused by the data loop. Compared with the prior art, the present invention implements a communication middleware for heterogeneous networks, and completes intra-machine and inter-machine communication by adopting data distribution services. It supports intra-machine and inter-machine publish-subscribe, remote procedure call two communication modes, both of which support service quality policy qos configuration, and support custom transmission structure serialization and deserialization. The middleware can help drone clusters share sensor data, location information and control instructions in real time under the condition of low bandwidth between machines, and realize collaborative work and cluster decision-making.

[0125] The present invention enables users to use a set of interfaces for intra-machine and inter-machine communication. The proxy completes the message type conversion of the two data distribution services, solving the problem that a large amount of work needs to be repeated when cross-machine nodes communicate with each other.

[0126] It should be pointed out that the specific implementation methods described above can enable those skilled in the art to understand the invention more comprehensively, but do not limit the invention in any way. Therefore, although the invention has been described in detail in this specification and embodiments, those skilled in the art should understand that the invention can still be modified or replaced by equivalents; and all technical solutions and improvements that do not deviate from the spirit and scope of the invention are included in the protection scope of the invention. Any figure mark in the claims should not be regarded as limiting the claims involved. Any simple change or equivalent replacement of the technical solution that can be obviously obtained by any technician familiar with the field within the technical scope disclosed in the present invention belongs to the protection scope of the present invention.

Claims

1. A communication middleware for heterogeneous networks, characterized in that: It includes an agent module set on each drone in the drone cluster, and the agent modules on different drones realize inter-machine communication through the data distribution service NetDDS; The proxy module is used to receive a request sent by a communication entity of a drone in a drone cluster, establish a tunnel of a corresponding topic according to the request, so that the request is transmitted to the proxy module on the target drone through the tunnel via the data distribution service NetDDS, and send the request to the communication entity of the target drone through the proxy module on the target drone; The proxy module is also used to adopt a remote procedure call mechanism based on data distribution service and use the publish-subscribe mode to realize the request and response communication between the client and the server, specifically including: Each remote call request contains a globally unique identifier GUID, which is used to identify which specific client the request comes from; each request also contains a sequence number, which is used to uniquely identify the request from the specific client so that the client can correctly match the received response; after receiving the request, the server needs to return the request header intact in the response, and the returned content includes the GUID and sequence number; the client filters out requests that are not initiated by itself based on the GUID, and obtains the response data corresponding to the request based on the sequence number; The proxy module is also used to complete the forwarding logic of the publish-subscribe related tunnels and provide a unified interface for creating publishers and subscribers; the forwarding logic of the publish-subscribe related tunnels specifically includes the forwarding logic of the export publishing tunnel OutRTPSTunnel and the forwarding logic of the import subscription tunnel InRTPSTunnel; The forwarding logic of the egress publishing tunnel OutRTPSTunnel is as follows: Register the FastDDS subscriber new data arrival event in the constructor; After the event is triggered, the serialized data is taken into the buffer; it is determined whether the data comes from the entry tunnel of the same topic. If so, the data is ignored; if not, the NetDDS publisher will publish the byte stream in the buffer; The forwarding logic of the ingress subscription tunnel InRTPSTunnel is: Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer; After obtaining it, the publisher of FastDDS publishes the byte stream.

2. The communication middleware for heterogeneous networks according to claim 1, characterized in that: The proxy module communicates with the corresponding communication entity through the UAV's internal data distribution service FastDDS.

3. The communication middleware for heterogeneous networks according to claim 2, characterized in that: The communication entities include publishers, subscribers, servers and clients.

4. The communication middleware for heterogeneous networks according to claim 3, characterized in that: The proxy module starts a server of a specific topic FastDDS through a remote procedure call on FastDDS, and listens to the proxy request initiated by the unified interface; after receiving the proxy request, in the initial entity creation request, an export RTPS tunnel is created for the publisher; For subscribers, an entry RTPS tunnel is created; For the client, an egress request tunnel and an ingress response tunnel are created; For the server, an ingress request tunnel and an egress response tunnel are created.

5. The communication middleware for heterogeneous networks according to claim 4, characterized in that: The proxy module is also used to increase the reference count of the corresponding tunnel by 1 in the subsequent entity creation request; during the entity destruction process, the reference count of the corresponding tunnel is reduced by 1, and if the reference count is 0, the tunnel is destroyed.

6. The communication middleware for heterogeneous networks according to claim 4, characterized in that: The proxy module is also used to complete the forwarding logic of the request-response related tunnels and provide a unified interface for creating a client and a server; the forwarding logic of the request-response related tunnels specifically includes the forwarding logic of the egress request tunnel OutRequestTunnel and the forwarding logic of the ingress response tunnel InResponseTunnel; The forwarding logic of the egress request tunnel OutRequestTunnel is as follows: Register the FastDDS subscriber new data arrival event in the constructor; After the event is triggered, new data is taken out to the forwarding buffer; Use the GUID filter to determine whether the data comes from the same topic entry tunnel. If so, ignore it. If not, take out the sequence number on the sample_identity of the data and the GUID on the related_sample_identity. Use the sequence number as the key to take out the GUID and sequence number on the value from the mapping table and serialize them to the end of the buffer. Byte stream of the buffer published by the NetDDS publisher; The forwarding logic of the ingress response tunnel InResponseTunnel is as follows: Start the forwarding thread, which continuously fetches the queue data of QueuingSubscriber on NetDDS into the tunnel buffer; Take out the GUID and serial number from the end of the buffer, and then the FastDDS publisher publishes the data to obtain the serial number of this publication. Use the serial number as the key and the previously taken GUID and serial number as the value to store them in the mapping table, and load the GUID and serial number to related_sample_identity. The ingress request tunnel and the egress response tunnel are related to the server. A pair of tunnels under the same service name need to share a sequence number mapping table and correctly complete the forwarding of the sequence number according to the mapping table.

7. The communication middleware for heterogeneous networks according to claim 4, characterized in that: The proxy module is also used to control the traffic flowing out of a drone's exit tunnel to flow into the drone's entry tunnel of the same topic, specifically: When creating an inlet tunnel, the GUID of the publisher on FastDDS is taken and stored in the GUID filter; when forwarding data on the egress tunnel, the GUID of the data publisher is taken. If there is an inlet tunnel with the same topic and the GUID matches, the data will not be forwarded, otherwise it will be forwarded.

Images