Plug-in command and control framework building method for vehicle-mounted platform

Abstract

The application provides a plug-in type command control framework construction method for a vehicle-mounted platform, which is designed based on a Qt framework, a C++ language environment and an OSGi standard, can realize decoupling between different function modules, dynamic loading and unloading of modules and services and the like through plug-ins, and realizes communication between different plug-ins based on an event mechanism and a signal slot mechanism, so that the design and development difficulty of the control framework is greatly reduced, and the expansibility of a finished system is improved. The command control framework constructed based on the method can realize remote control and state reading of multiple unmanned vehicles, one-machine multi-control and multi-machine multi-control of the unmanned vehicles by means of a 4G network, and can also support communication of a ROS system.

Description

Technical Field

[0001] This invention belongs to the field of vehicle platform control system development technology, specifically relating to a method for constructing a plug-in command and control framework for vehicle platforms. Background Technology

[0002] Current automotive platform development often employs a deployment approach that integrates various functional modules. This approach suffers from several drawbacks, including a lack of a unified mechanism for module calls, leading to dependency confusion; redundant development of common modules resulting in resource waste; high coupling between modules, causing cascading changes; and poor system scalability. These issues severely restrict control system development. Service-oriented architecture (SOA)-based automotive platform architectures, such as OSGi, can overcome these shortcomings to some extent by incorporating SOA principles during development. They enable complex processing through plug-in systems and offer relatively lower development difficulty. However, current mainstream OSGi frameworks, such as Equinox and Apache Felix, are mostly based on Java. While Java has a relatively clear software structure, its slow execution speed makes it unsuitable for building high-performance graphics software. C++-based OSGi frameworks, such as CTK Plugin Framework and C++ Micro Services, offer better performance, but their programming APIs are somewhat disorganized and unsuitable for GUI development. Furthermore, the data exchange methods provided by the OSGi framework itself are limited, relying solely on services for data transfer, which hinders signal interaction during large-scale development. For command and control of unmanned vehicle clusters implemented through vehicle-mounted platforms, such as the functions of one machine controlling multiple vehicles and multiple machines controlling multiple vehicles, the existing command and control framework cannot meet the requirements in terms of communication efficiency between components and system scalability. Summary of the Invention

[0003] In view of this, and to address the technical problems existing in this field, the present invention provides a method for constructing a plug-in command and control framework for an onboard platform, specifically including the following steps:

[0004] Step 1: Design the command and control framework structure based on the Qt framework. The framework structure includes a software framework designed according to an OSGi standard, supporting plug-in development and coded in C++, and several specific communication function modules. The framework structure is used to decompose the interaction between the single vehicle and the cluster command and control of the unmanned vehicle into several services. After the design is completed, move the entire framework file to the created project folder.

[0005] Step 2: Code each module in the framework. First, code the launcher module, which creates a context resolver and reads the corresponding XML configuration file. The XML configuration file records the order in which the plugins are launched and the plugins to be launched. Then, according to the file directory and file name indicated in the configuration file, use the loadlibrary function to load the plugin dynamic library. After loading, call the init function of each module to pass the context object QObject to each module, then call the start function to make each module complete the registration of services and events, and finally enter the exec() function main event loop.

[0006] Step 3: Create each plugin according to specific needs. Each plugin consists of two parts: a pluginActivator and a plugin file. The pluginActivator corresponds to the interface between the plugin and the control framework, providing the following functions to perform different interface plugin operations: `stop` function: stops the plugin, deletes all objects created by the plugin, and unregisters all services created by the plugin; `start` function: starts the plugin and creates a series of objects for interaction with the system; `init` function: obtains the context object `QObject`, which must be called before starting the plugin; `postevent` function: broadcasts events to enable communication between different plugins; `subscribevent` function: registers the events that each module needs to subscribe to; `subscr` function: subscribes to events; `subscribevent ... The `ibeslot` slot function is used to subscribe to signals that call other plugins; the `publishsignal` function is used to declare the signals emitted by the module; the `registerservice` function is used to register services; the `getService` function is used to obtain the service interface; the `plugin` file is the project configuration file; the `start` function creates several `QObject` objects that are private members of `pluginActivator`, and initializes them when `pluginActivator` is constructed; each `QObject` object corresponds to a different specific service, and after the `QObject` object is created, the corresponding service is also registered to the context, and the object providing each service can be obtained using the `getService` function;

[0007] Step 4: Establish a communication mechanism between different plugins based on the event mechanism and the signal-slot mechanism. The event mechanism specifically includes setting the Eventservice header file when each plugin is created. The Eventservice contains the eventtriggered function interface, which can call different events through the input parameter XTLevent, thereby realizing the object's response to one or more events. The signal-slot mechanism specifically utilizes the signals sent and received between different objects QObject, as well as the publishsignal function and the subscribeslot slot function to realize the response of the called object to the executing calling object.

[0008] Step 5: Establish a ROS communication mechanism between the host computer and the slave computer using multiple communication protocols. This includes dividing the control framework's communication protocol into a three-layer structure: application layer, protocol layer, and stream layer. On the host computer, the ROS module is used to subscribe to topics in ROS and obtain data from the application layer. This data is then converted to the protocol layer, and finally, a serialization module is used to convert the protocol layer data into hexadecimal code. The open-source communication protocol module MQTT is called to send the stream to the slave computer. On the slave computer, the same three-layer communication protocol structure as the host computer is used. After obtaining the stream, the protocol layer and application layer are used to deserialize it to obtain the corresponding data. The ROS module is then used to republish this data as a topic in ROS. This allows for one-to-many or multi-to-multiple-machine control when different autonomous vehicles act as host or slave computers, respectively, through topic pass-through. Specifically, subscribing to topics in ROS involves obtaining the corresponding services and objects through the getService function and then making calls.

[0009] This completes the construction of the plug-in command and control framework for the vehicle platform.

[0010] Furthermore, by configuring the project files during the construction of the control framework, the entire framework and its various plugins can be ported and run across Linux, Windows, and MacOS platforms without modifying the software code.

[0011] Furthermore, the getService function obtains the service interface by first storing all service objects and their corresponding names in a QMap object through the registerservice function. This allows the control framework to find the object corresponding to a certain service from the QMap and, based on the RTTI mechanism, uses the dynamic_cast operator to convert the service pointer to point to the requester of that service.

[0012] Furthermore, the creation, modification, dependency configuration, and service creation of the plugins are all implemented through Feaetherweight.

[0013] Furthermore, the event mechanism utilizes XTLevent specifically as a dictionary, which is used to insert the event name and event attributes into the object. Then, the postevent function is used to broadcast the event to achieve information interaction between different plugins. In order for plugins to respond to events, the objects that need to respond to events should inherit the eventtriggered function interface of Eventservice. The implementation of this interface encodes the response to the event, and then the subscribevent function is called to register the object in QMap. The postevent function finds the objects that have subscribed to the event according to the event name and calls their eventtriggered function to complete the response to the event.

[0014] Furthermore, in the signal and slot mechanism, the control framework maintains a list of signals and slots. When an object in the plugin calls the `publishsignal` or `subscribeslot` function, the system adds the object to this list and compares it with a signal already registered in the list. If they match, the object is associated with the corresponding signal or slot. In this way, application developers can subscribe to or emit signals at any point in the plugin without simultaneously holding pointers to both the object sending the signal and the object responding to the signal, thus improving the flexibility of the signal and slot mechanism.

[0015] Furthermore, the host computer and the slave computer each have different IDs and can be registered to the same MQTT server. At this time, topics published by the same host computer or slave computer can be subscribed to by multiple slave computers or other host computers, so that the control framework can distribute the control of the slave computer to different host computers, realizing the functions of one machine to multiple control and multiple machines to multiple control.

[0016] Furthermore, each layer of the communication protocol can select and switch between communication protocols such as RCS, Bluetooth, LoRa, Zigbee, and MQTT according to actual needs and hardware configuration.

[0017] Furthermore, the control framework also includes a real-time video transmission module, which uses ffmpeg to perform software decoding of image data streams and, in conjunction with the player embedded in the control framework, uses the RTMP protocol to realize image transmission between the host computer and the slave computer; and a map module, which supports the use of Baidu Map API and Gaode Map API to realize the positioning, trajectory planning and trajectory tracking of the slave computer unmanned vehicle. The map module also embeds the ROS visualization tool RVIZ into the window interface of the control framework to realize the visualization of ROS related data.

[0018] The plug-in command and control framework construction method for vehicle platforms provided by the present invention is based on the Qt framework and C++ language environment and designed according to the OSGi standard. It enables decoupling between different functional modules, dynamic loading and unloading of modules and services, and communication between different plug-ins based on event and signal / slot mechanisms. This significantly reduces the design and development difficulty of the control framework and improves the scalability of the finished system. The command and control framework built based on this method can remotely control and read the status of multiple unmanned vehicles via 4G networks, as well as enable one-to-many and multi-to-multiple unmanned vehicles, and also supports communication using the ROS system. Attached Figure Description

[0019] Figure 1 This is a control framework diagram constructed based on the method provided by the present invention;

[0020] Figure 2 This is a flowchart illustrating the operation of the control framework constructed based on the method provided in this invention. Detailed Implementation

[0021] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The command and control framework structure constructed by the method provided in this invention is as follows: Figure 1 As shown, the method specifically includes the following steps:

[0023] Step 1: Design the command and control framework structure based on the Qt framework. The framework structure includes a software framework designed according to an OSGi standard, supporting plug-in development and coded in C++, and several specific communication function modules. The framework structure is used to decompose the interaction between the single vehicle and the cluster command and control of the unmanned vehicle into several services. After the design is completed, move the entire framework file to the created project folder.

[0024] Step 2: Code each module in the framework. First, code the launcher module, which creates a context resolver and reads the corresponding XML configuration file. The XML configuration file records the order in which the plugins are launched and the plugins to be launched. Then, according to the file directory and file name indicated in the configuration file, use the loadlibrary function to load the plugin dynamic library. After loading, call the init function of each module to pass the context object QObject to each module, then call the start function to make each module complete the registration of services and events, and finally enter the exec() function main event loop.

[0025] Step 3: Create each plugin according to specific needs. Each plugin consists of two parts: a pluginActivator and a plugin file. The pluginActivator corresponds to the interface between the plugin and the control framework, providing the following functions to perform different interface plugin operations: `stop` function: stops the plugin, deletes all objects created by the plugin, and unregisters all services created by the plugin; `start` function: starts the plugin and creates a series of objects for interaction with the system; `init` function: obtains the context object `QObject`, which must be called before starting the plugin; `postevent` function: broadcasts events to enable communication between different plugins; `subscribevent` function: registers the events that each module needs to subscribe to; `subscr` function: subscribes to events; `subscribevent ... The `ibeslot` slot function is used to subscribe to signals that call other plugins; the `publishsignal` function is used to declare the signals emitted by the module; the `registerservice` function is used to register services; the `getService` function is used to obtain the service interface; the `plugin` file is the project configuration file; the `start` function creates several `QObject` objects that are private members of `pluginActivator`, and initializes them when `pluginActivator` is constructed; each `QObject` object corresponds to a different specific service, and after the `QObject` object is created, the corresponding service is also registered to the context, and the object providing each service can be obtained using the `getService` function;

[0026] Step 4: Establish a communication mechanism between different plugins based on the event mechanism and the signal-slot mechanism. The event mechanism specifically includes setting the Eventservice header file when each plugin is created. The Eventservice contains the eventtriggered function interface, which can call different events through the input parameter XTLevent, thereby realizing the object's response to one or more events. The signal-slot mechanism specifically utilizes the signals sent and received between different objects QObject, as well as the publishsignal function and the subscribeslot slot function to realize the response of the called object to the executing calling object.

[0027] Step 5: Establish a ROS communication mechanism between the host computer and the slave computer using multiple communication protocols. This includes dividing the control framework's communication protocol into a three-layer structure: application layer, protocol layer, and stream layer. On the host computer, the ROS module is used to subscribe to topics in ROS and obtain data from the application layer. This data is then converted to the protocol layer, and finally, a serialization module is used to convert the protocol layer data into hexadecimal code. The open-source communication protocol module MQTT is called to send the stream to the slave computer. On the slave computer, the same three-layer communication protocol structure as the host computer is used. After obtaining the stream, the protocol layer and application layer are used to deserialize it to obtain the corresponding data. The ROS module is then used to republish this data as a topic in ROS. This allows for one-to-many or multi-to-multiple-machine control when different autonomous vehicles act as host or slave computers, respectively, through topic pass-through. Specifically, subscribing to topics in ROS involves obtaining the corresponding services and objects through the getService function and then making calls.

[0028] This completes the construction of the plug-in command and control framework for the vehicle-mounted platform, and its operation process is as follows: Figure 2 As shown, various command and control functions are implemented through services between plugins. For example, in pluginA, an object `object_a` is created to provide a service `service_A`. This requires opening the Featherweight software, navigating to service creation, entering the service name `service_A`, creating the service, and then including the header file `service / service_A` in the `object_a` header file, making `object_a` inherit this interface. At this point, `object_a` becomes the service provider, and the service can be registered in the context by calling the interface function `registerservice(object_a, 'service_A')` in pluginA.

[0029] Suppose the interface name of the above service is method_A, and another plugin needs to call the function of this interface. Then, the getService interface is called in plugin B. This will return a pointer to object_a. After plugin B holds this pointer, it can directly call its interface to use method_a.

[0030] In a preferred embodiment of the present invention, by configuring the project files during the construction of the control framework, the entire framework and its plugins can be ported and run across Linux, Windows, and MacOS platforms without modifying the software code.

[0031] In a preferred embodiment of the present invention, the getService function obtains the service interface by first storing all service objects and their corresponding names in a QMap object through the registerservice function. This allows the control framework to find the object corresponding to a certain service from the QMap and, based on the RTTI mechanism, use the dynamic_cast operator to convert the service pointer to point to the requester of the service.

[0032] In a preferred embodiment of the present invention, the creation, modification, dependency configuration, and service creation of the plugin are all implemented through Feaetherweight.

[0033] In a preferred embodiment of the present invention, the event mechanism utilizes an XTLevent dictionary to insert event names and attributes into the object. The postevent function is then used to broadcast the event, enabling information exchange between different plugins. For example, suppose plugins A and B both need to subscribe to event C, which is emitted by plugin C. In this case, the header files of the functional classes of plugins A and B include the Eventservice.h file, and they inherit from this class, overriding the corresponding eventtriggered interface. The input parameter type of this interface is XTLevent, which contains a name attribute eventname. If a plugin needs to subscribe to multiple events, it can check the eventname before executing the specific response, comparing it with the event names in the event list, and then respond. After completing the implementation of eventtriggered, the subscribevent function needs to be called in the function body to declare the event names subscribed to by the object. After the above process is completed, you can create an XTLevent class object `event` in the C plugin, assign values ​​to the name and properties of `event`, and then call the `postevent` interface to broadcast the event. At this time, if there are any objects that have subscribed to the event, their `eventtriggered` function will be executed.

[0034] In a preferred embodiment of the present invention, the signal-slot mechanism involves a control framework maintaining a list of signal slots. When an object in the plugin calls the `publishsignal` or `subscribeslot` function, the system adds the object to the list and compares it with a signal already registered in the list. If the match is found, the object is associated with the corresponding signal or slot. In this way, application developers can subscribe to or emit signals at any point in the plugin without simultaneously holding pointers to both the object sending the signal and the object responding to the signal, thus improving the flexibility of the signal-slot mechanism. For example, if object_a emits the signal sig_dosomething() and object_b receives the signal slot_dosomething(), then plugin A can call the interface function publishsignal(object_a,SIGNAL(sig_dosomething),'dosomething') in the pluginActivator file of the control framework, and plugin B can call the interface function subscribeslot(object_b,SLOT(sig_dosomething),'dosomething'). The software system will automatically connect the signal and the slot function. After that, calling the signal of object_a anywhere will trigger the slot function response of object_b.

[0035] In a preferred embodiment of the present invention, the host computer and the slave computer each have different IDs and can be registered to the same MQTT server; at this time, topics published by the same host computer or slave computer can be subscribed to by multiple slave computers or other host computers, so that the control framework can allocate the control of the slave computer to different host computers, realizing the functions of one machine for multiple control and multiple machines for multiple control.

[0036] In a preferred embodiment of the present invention, the communication protocol layers select and switch between communication protocols such as RCS, Bluetooth, LoRa, Zigbee, and MQTT according to actual needs and hardware configuration.

[0037] In a preferred embodiment of the present invention, the control framework further includes a real-time video transmission module, which uses ffmpeg to perform software decoding of image data streams and, in conjunction with the player embedded in the control framework, uses the RTMP protocol to realize image transmission between the host computer and the slave computer; and a map module, which supports the use of Baidu Map API and Gaode Map API to realize the positioning, trajectory planning and trajectory tracking of the slave computer unmanned vehicle. The map module also embeds the ROS visualization tool RVIZ into the window interface of the control framework to realize the visualization of ROS related data.

[0038] It should be understood that the sequence number of each step in the embodiments of the present invention does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0039] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for constructing a plug-in command and control framework for a vehicle-mounted platform, characterized in that: Specifically, the following steps are included: Step 1: Design the command and control framework structure based on the Qt framework. The framework structure includes a software framework designed according to an OSGi standard, supporting plug-in development and coded in C++, and several specific communication function modules. The framework structure is used to decompose the interaction between the single vehicle and the cluster command and control of the unmanned vehicle into several services. After the design is completed, move the entire framework file to the created project folder. Step 2: Code each module in the framework. First, code the launcher module, which creates a context resolver and reads the corresponding XML configuration file. The XML configuration file records the order in which the plugins are launched and the plugins to be launched. Then, according to the file directory and file name indicated in the configuration file, use the loadlibrary function to load the plugin dynamic library. After loading, call the init function of each module to pass the context object QObject to each module, then call the start function to make each module complete the registration of services and events, and finally enter the exec() function main event loop. Step 3: Create each plugin according to specific requirements. Each plugin consists of two parts: a pluginActivator and a plugin file. The pluginActivator corresponds to the interface between the plugin and the control framework, providing the following functions to perform different interface plugin operations: the stop function, used to stop the plugin, delete all objects created by the plugin, and unregister all services created by the plugin; the start function, used to start the plugin and create a series of objects for interacting with the system; and the init function, used to obtain the context object QObject, which must be called before starting the plugin. The `postevent` function is used to broadcast events, enabling communication between different plugins; the `subscribevent` function is used to register events that each module wants to subscribe to; the `subscribeslot` function is used to subscribe to signals that call other plugins; the `publishsignal` function is used to declare signals emitted by a module; the `registerservice` function is used to register services; and the `getService` function is used to obtain the service interface. The plugin file is the project configuration file; in the start function, several objects QObject are created as private members of pluginActivator and initialized when pluginActivator is constructed; each object QObject corresponds to a different specific service, and after the object QObject is created, the corresponding service is also registered to the context, and the object providing each service can be obtained by using the getService function; Step 4: Establish a communication mechanism between different plugins based on the event mechanism and the signal-slot mechanism. The event mechanism specifically includes setting the Eventservice header file when each plugin is created. The Eventservice contains the eventtriggered function interface, which can call different events through the input parameter XTLevent, thereby realizing the object's response to one or more events. The signal-slot mechanism specifically utilizes the signals sent and received between different objects QObject, as well as the publishsignal function and the subscribeslot slot function to realize the response of the called object to the executing calling object. Step 5: Establish a ROS communication mechanism between the host computer and the slave computer using multiple communication protocols. This includes dividing the control framework's communication protocol into a three-layer structure: application layer, protocol layer, and stream layer. On the host computer, the ROS module is used to subscribe to topics in ROS and obtain data from the application layer. This data is then converted to the protocol layer, and finally, a serialization module is used to convert the protocol layer data into hexadecimal code. The open-source communication protocol module MQTT is called to send the stream to the slave computer. On the slave computer, the same three-layer communication protocol structure as the host computer is used. After obtaining the stream, the protocol layer and application layer are used to deserialize it to obtain the corresponding data. The ROS module is then used to republish this data as a topic in ROS. This allows for one-to-many or multi-to-multiple-machine control when different autonomous vehicles act as host or slave computers, respectively, through topic pass-through. Specifically, subscribing to topics in ROS involves obtaining the corresponding services and objects through the getService function and then making calls.

2. The method as described in claim 1, characterized in that: By configuring the project files during the construction of the control framework, the entire framework and its plugins can be ported and run across Linux, Windows, and MacOS platforms without modifying the software code.

3. The method as described in claim 1, characterized in that: The getService function retrieves the service interface by first storing all service objects and their corresponding names in a QMap object using the registerservice function. This allows the control framework to find the object corresponding to a service from the QMap and, based on the RTTI mechanism, uses the dynamic_cast operator to convert the service pointer to point to the requester of that service.

4. The method as described in claim 1, characterized in that: The creation, modification, dependency configuration, and service creation of the plugins are all implemented through Feaetherweight.

5. The method as described in claim 1, characterized in that: The event mechanism utilizes XTLevent, specifically a dictionary, to insert event names and attributes into the object. The postevent function then broadcasts the event, enabling information exchange between different plugins. For a plugin to respond to an event, the object that needs to respond should inherit the eventtriggered function interface of Eventservice. The implementation of this interface encodes the event response, and then the subscribevent function is called to register the object in the QMap. The postevent function then searches for objects that have subscribed to the event by name and calls their eventtriggered function, thus completing the event response.

6. The method as described in claim 1, characterized in that: In the aforementioned signal and slot mechanism, the control framework maintains a list of signals and slots. When an object in the plugin calls the publishsignal or subscribeslot function, the system adds the object to the list and compares whether the newly added object matches the signals already registered in the list. If they match, the object is connected to the corresponding signal or slot.

7. The method as described in claim 1, characterized in that: The host computer and the slave computer each have different IDs and can be registered to the same MQTT server. At this time, topics published by the same host computer or slave computer can be subscribed to by multiple slave computers or other host computers, so that the control framework can distribute the control of the slave computer to different host computers, realizing the functions of one machine to multiple control and multiple machines to multiple control.

8. The method as described in claim 1, characterized in that: The communication protocol layers can be selected and switched between RCS, Bluetooth, LoRa, Zigbee, and MQTT communication protocols according to actual needs and hardware configuration.

9. The method as described in claim 1, characterized in that: The control framework also includes a real-time video transmission module, which uses ffmpeg to perform software decoding of image data streams and, in conjunction with the player embedded in the control framework, uses the RTMP protocol to realize image transmission between the host computer and the slave computer. It also includes a map module for positioning, trajectory planning, and trajectory tracking of the lower-level unmanned vehicle. The map module also embeds the ROS visualization tool RVIZ into the window interface of the control framework to visualize ROS-related data.

Images