Open-type configurable two-dimensional stabilized platform control board card software architecture

Abstract

The invention discloses an open type configurable software architecture applied to a two-dimensional stable platform control board card, and aims to solve the problems that a traditional control board card is solidified in software function, difficult to configure and poor in expansibility. The architecture is divided into an access layer, a service layer, an interface layer and a bottom layer from bottom to top, and the core is to construct a layered and modularized software system. The method is characterized in that dynamic modular design is adopted, multiple functions are decoupled into independent and pluggable algorithm modules, and the modules interact according to IPC specifications; driving execution is configured, a user can select and combine algorithm modules and set parameters in real time through upper computer software, and firmware codes do not need to be modified; an open SDK is provided, allowing a third-party developer or a user to customize a new algorithm module and integrate the new algorithm module into an existing architecture. The universality, the flexibility and the expandability of the control board card are greatly improved, and the development cycle for different application scenes is obviously shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of two-dimensional stable platform control, and particularly relates to an open and configurable software architecture applied to a two-dimensional stable platform control board card. BACKGROUND

[0002] The software of the control board card of a traditional two-dimensional stable platform, such as a photoelectric pod or a radar antenna, generally adopts an integrated and closed architecture. This architecture tightly integrates all functions, such as sensor data acquisition, attitude calculation, stable control, servo drive and the like, in one or a few tasks. The problem of such an architecture is increasingly obvious. If an algorithm is to be replaced, such as replacing a PID stable algorithm with an ADRC algorithm, or adjusting the combination mode of the algorithm, it basically means that the entire firmware needs to be redeveloped, and the original manufacturer needs to be relied on for support, and the development cycle is particularly long. Moreover, parameter adjustment is also troublesome, and the code usually needs to be changed, the firmware needs to be recompiled and burned, and it is not possible to quickly optimize and test on site. Users also cannot add some custom function modules according to their special needs, such as special motion trajectory planning and linkage of specific loads, which cannot be done. In addition, different project requirements may need to maintain several firmware branches, which is messy and inefficient to manage. Therefore, there is an urgent need for a control board card software architecture that can be flexibly configured and expanded by users like configuring computer software. SUMMARY

[0003] 3.1 The present application is to solve the problems of rigidification, inconvenience of configuration and difficulty of expansion of the stable platform control board card software architecture in the prior art, and provides a flexible, open and easy-to-customize software solution. Technical solution 3.2 In order to achieve this purpose, the open and configurable two-dimensional stable platform control board card software architecture proposed by the present application is divided into four levels from bottom to top: 3.2.1 Access layer: This layer is used for human-computer interaction, and is mainly responsible for external access, with API serial port and Web page access; 3.2.2 Business layer: divided into algorithm and application service. The algorithm part contains a number of algorithm modules required by the two-dimensional stable platform, such as position closed loop, trajectory interpolation, cooperative filtering, path planning, track extrapolation, multi-axis synchronization, attitude stabilization, analog anti-backlash and the like; the application service part has functions such as IO control, console, fault analysis, OTA upgrade, parameter configuration, communication analysis and the like, so as to make the software ecology more perfect; 3.2.3 Interface layer: provides a variety of interfaces, such as I / O interface, serial port (such as RS422A, RS422B, RS485A, RS485B, RS232 and the like), CAN interface and SPI interface and the like, for communication with other devices or systems; 3.2.4 Bottom layer: based on RT-Thread 5.0 operating system, containing GD32F4 library and multiple components such as FINSH, FAL, SFUD, WebNet, cJSON, LittleFS, SysViwer, OTA-FOTA, etc., supporting OTA-FOTA upgrade and other functions. In addition, the architecture is also matched with PC end configuration host computer and software development kit (SDK). 3.3 Advantages Compared with the prior art, the advantages of the present application are obvious: 3.3.1 High flexibility and configurability: users can select algorithm modules and combination modules through the matched host computer software without changing firmware codes, and can also real-time set parameters to realize the "what you see is what you get" rapid customization; 3.3.2 Strong expansibility: the open SDK allows users with development capabilities to write new algorithm modules and then integrate them into the system, which can meet special or secret application requirements and break through the technical barriers of the original factory; 3.3.3 High development and maintenance efficiency: algorithm modules can be reused, new project development can be quickly built based on the existing module library, and function upgrade only needs to update or add a single module without changing the entire system architecture, which is very simple to maintain; 3.3.4 High reliability: modules are decoupled, so that a problem in a module does not easily cause the entire system to crash, which facilitates problem finding and fault isolation. DETAILED DESCRIPTION 4.1 Detailed explanation of overall architecture The software architecture of the present application adopts hierarchical design to realize a complete closed loop from user instructions to device execution, and the specific conditions of each layer are as follows: 4.1.1 Access layer: As the link between users and the system, this layer accurately converts the user's operation intention into process instructions that the system can execute through a dual-mode communication mechanism. It innovatively combines the standard serial interface and the IEEE 802.3 standard Ethernet interface, forming a complementary hardware channel system. The serial port channel uses a hexadecimal instruction frame transmission protocol to meet the high real-time requirement of industrial field bottom-layer control; the network channel builds a Web management interface based on the B / S architecture, allowing users to intuitively complete complex operations such as parameter configuration through a browser. This dual-operation mode of "instruction-driven + graphical interaction" not only retains the command-line control efficiency familiar to professional users, such as directly sending structured instruction frames through the serial port, but also provides ordinary users with a click-type operation experience that allows them to see the results directly. In actual use, engineers can first connect through the network port to complete visual configuration of system parameters, then switch to the serial port channel to send motion control instructions, and finally complete the precise execution of complex working conditions such as fan scanning mode, with the entire process showing smooth cooperation between hardware interfaces and software logic. 4.1.2 Business layer: Algorithm part: The algorithm kernel uses a modular architecture design, with eight intelligent control modules as the core, including position closed-loop control, trajectory interpolation algorithm, adaptive collaborative filtering, track prediction extrapolation, multi-axis synchronization control, safety threshold protection, attitude stabilization algorithm, and analog anti-backlash compensation. Each module is dynamically bound through function pointers and can be hot-plugged. Users can select according to actual conditions, such as enabling the track prediction module when precise scanning mode is required, and turning off unnecessary compensation algorithms during regular operation. This configurable algorithm set design makes the system more adaptable. Application service part: The application service layer builds a complete intelligent operation and maintenance ecological chain, including programmable IO control, real-time console, fault tree analysis, over-the-air upgrade, parameter visual configuration, and communication protocol analysis. Among them, the intelligent IO strategy engine supports user-defined output logic, combined with fault prediction and health management systems for fault root cause analysis. Through the secure OTA channel and remote configuration management function, engineers can complete operations such as firmware over-the-air upgrade, greatly reducing the need for on-site service and allowing devices to achieve autonomous management at the edge. 4.1.3 Interface layer: A complete device interconnection solution is built with an industrial-grade multi-protocol fusion design. In terms of physical interfaces, there are programmable digital I / O channels (supporting opto-isolation and over-current protection), dual-redundant RS422 serial interfaces (compliant with TIA / EIA-422-B standard), dual-node RS485 bus (supporting Modbus RTU protocol), and CAN 2.0B controller compliant with ISO 11898-2 specification. In addition, a high-speed SPI master-slave interface is integrated, supporting dynamic clock frequency configuration. All interfaces are protected by ESD protection circuits and protocol conversion engines to ensure signal integrity, meeting the stable communication requirements in harsh industrial environments. This architecture also specially designs a cross-interface data transparent transmission mechanism, which can flexibly adapt to the access requirements of different peripheral devices such as PLC and sensor networks. 4.1.4 Bottom layer: Based on RT-Thread 5.0 operating system, it has high stability and reliability, and through its hard real-time kernel and modular design, it realizes deterministic delay with task response time ≤10μs. The system deeply integrates the GD32F4 series MCU standard peripheral library, providing register-level operation optimization, supporting DMA accelerated data transmission and hardware CRC verification. The bottom layer supports OTA-FOTA upgrade, enabling remote firmware update, using AES-256 encrypted transmission and digital signature verification mechanism to ensure that the firmware update process complies with IEC 62443-4-1 security standards. There are also key components such as FINSH debugging console, FAL flash abstraction layer, cJSON parsing library, SFUD storage device driving framework, LittleFS file system, SysViwer system view tool, WebNet network library, etc., which together improve the system's functionality and performance. The overall design ensures efficient operation and flexible expansion of the system, providing strong support for upper-layer applications. 4.2 Framework principles The system adopts hierarchical design, and completes the complete closed loop from user instruction to device execution. After the user submits the control instruction through the API serial port or the Web interface of the top layer, the communication module of the access layer immediately performs data unpacking and protocol analysis on the original instruction, and reports the structured instruction to the core processing layer. The operation and control module of the business layer serves as the control center, generates accurate motion control parameters according to the instruction requirements, and transmits the driving instruction to the driving unit of the interface layer through the bottom layer interface. The driver converts the digital control signal into physical power output, and drives the motor actuator to make mechanical action. The system collects the motor running state in real time through the high-precision encoder, and feeds back the detection data to the state detection module for real-time analysis. The detection module synchronously transmits the device running state data back to the business layer and the access layer, forming a complete control closed loop of “instruction - execution - feedback”, and ensuring that the system can stably and reliably run in dynamic adjustment. The core idea of the system is to split the complex control system into small parts. Each functional unit, like “PID controller” “S-type curve planner” “Kalman filter”, is packaged into an independent “algorithm module”. All algorithm modules follow a unified standard interface, which is defined in the form of a C language function pointer structure (virtual function table), which ensures that modules can be interchanged and managed conveniently. In terms of module management and scheduling, there are module managers, internal data buses and execution schedulers. The module manager is responsible for maintaining the “registered module list”. When the system starts, it will scan all modules in the firmware that meet the standard interface, and register them in the list. When receiving the “activate module” or “disable module” instruction from the host computer, the manager will call the init or deinit function of the corresponding module to change its state. The internal data bus is the only channel for data interaction between modules, and is essentially a series of IPC services, including mailbox, semaphore, mutex. The sensor driver and other bottom layer tasks “publish” data to the bus, and the activated algorithm module “subscribes” the data it needs from the bus. This “publish - subscribe” mode makes the connection between modules less tight. The execution scheduler is a high-priority RTOS task that runs at a fixed high frequency. In each cycle, the scheduler will traverse the “registered module list”, and call the run function of all modules with the active state, which can ensure that all activated modules can execute in time and in real time. In the configuration drive and parameter management, there are parameter managers and configuration host computers. The parameter manager reads the "configuration table" from a specific area of the Flash and loads it into the RAM when the system is powered on. This table records whether each module is activated and all its configurable parameters, such as the P, I, and D values of the PID. After connecting to the board card, the configuration host computer sends the "query all modules" instruction first, and the board card returns the IDs, names, and parameter definitions of all registered modules, including parameter names, data types, and value ranges. The host computer then dynamically generates a graphical interface, and the user can check the modules to be activated, drag the slider or input numerical values to adjust the parameters. After clicking "Apply", the host computer packs the new configuration information and sends it to the board card through the communication protocol. The parameter manager of the board card receives the data, updates the parameters in the RAM, and writes them to the Flash for saving. BRIEF DESCRIPTION OF DRAWINGS Figure 1 is an overall layering diagram of the open configurable software architecture Figure 2 is an interlayer interaction process diagram Figure 3 is an interaction process diagram between the configuration host computer and the control board card.

Claims

1. An open, configurable, two-dimensional stable platform control board software architecture, characterized by four layers from bottom to top: an access layer, a service layer, an interface layer, and a bottom layer, as detailed below: 1.1 The access layer is used to provide human-computer interaction and is responsible for external access, including two access methods: API serial port and Web page; 1.2 The business layer is divided into two parts: algorithm and application service. The algorithm part covers a variety of algorithm modules required by the two-dimensional stability platform, and the application service part includes functions such as IO control, console, and fault analysis. 1.3 The interface layer provides a variety of interfaces, including I / O interfaces, serial ports, CAN interfaces, and SPI interfaces, for communication with other devices or systems; 1.4 Underlying technology is based on RT-Thread The 5.0 operating system includes the GD32F4 library and multiple components, supporting OTA-FOTA upgrades and other functions.

2. The software architecture according to claim 1, characterized in that, The system adopts a dynamic modular design, decoupling functions such as stability control, motion control, and positioning and orientation into independent, pluggable algorithm modules. Each module interacts according to the IPC specification, and all algorithm modules follow a unified standard interface, which is defined in the form of a C language function pointer structure (virtual function table).

3. The software architecture according to claim 1, characterized in that, The system enables configuration-driven execution and comes with host computer software. Users can select, combine, and tune the parameters of algorithm modules in real time without modifying the firmware code. The configuration information is persistently stored on the board. The configuration process is as follows: 3.1 After the host computer connects to the board, it sends the command "Query all modules"; 3.2 The board returns the MODULE_ID, MODULE_NAME and their parameter definitions for all registered modules, including parameter name, data type and value range; 3.3 The host computer dynamically generates a graphical interface, allowing users to select and activate modules and adjust parameters; 3.4 The host computer packages the new configuration information and sends it to the board. The board's parameter manager updates the parameters in RAM and writes them to Flash for persistence.

4. The software architecture according to claim 1, characterized in that, An open SDK is provided, allowing third-party developers or users to customize new algorithm modules and seamlessly integrate them into existing architectures; the system includes a module manager, internal data bus, and execution scheduler, as detailed below: 4.1 The module manager is responsible for maintaining the "list of registered modules". When the system starts, it scans all modules that conform to the standard interface and registers them. When it receives instructions from the host computer, it calls the init or deinit function of the corresponding module and changes its state. 4.2 The internal data bus is the only channel for data interaction between modules. In essence, it is a series of IPC services, including mailboxes, semaphores, mutexes, sensor drivers, and other low-level tasks that "publish" data to the bus. Activated algorithm modules "subscribe" to the required data from the bus. 4.3 The execution scheduler is a high-priority RTOS task that runs at a fixed high frequency. Each cycle iterates through the "registered module list" and calls the run function for all modules with state MODULE_ACTIVE.

5. The software architecture according to claim 1, characterized in that, The access layer converts user operation intentions into executable process instructions through a dual-mode communication mechanism, integrates two physical connection schemes: a standard serial interface and an IEEE 802.3 standard Ethernet interface, uses a hexadecimal instruction frame transmission protocol for the serial port channel, and constructs a web management interface based on a B / S architecture for the network channel.

6. The software architecture according to claim 1, characterized in that, The algorithm part of the business layer includes algorithm modules such as position closure, trajectory interpolation, collaborative filtering, path planning, trajectory extrapolation, multi-axis synchronization, attitude stabilization, and simulated backlash elimination. Each module is dynamically bound through function pointers and has hot-swappable characteristics. The application service part covers functions such as IO control, console, fault analysis, OTA upgrade, parameter configuration, and communication parsing.

7. The software architecture according to claim 1, characterized in that, The interface layer adopts an industrial-grade multi-protocol fusion design, providing programmable digital I / O channels, dual redundant RS422 serial interfaces, dual-node RS485 buses, CAN 2.0B controllers, and high-speed SPI master-slave interfaces. All interfaces are protected by ESD protection circuits and protocol conversion engines to ensure signal integrity, and a cross-interface data pass-through mechanism is designed.

8. The software architecture according to claim 1, characterized in that, The underlying layer is based on the RT-Thread 5.0 operating system, integrates the standard peripheral library of the GD32F4 series MCU, supports DMA accelerated data transmission and hardware CRC verification, and includes components such as FINSH, FAL, SFUD, WebNet, cJSON, LittleFS, SysViwer, and OTA-FOTA. It supports OTA-FOTA upgrades and adopts AES-256 encrypted transmission and digital signature verification mechanism.

Images