A multi-sensor access and data management micro-architecture system for intelligent controllers

Abstract

The present invention discloses a multi-sensor access and data management micro-architecture system of an intelligent controller, wherein a general processing module is used to support system initialization, singleton mode and multi-type data processing; a configuration file parsing module is used to receive user configuration instructions to perform targeted configuration on the used sensors, and organize the configuration information according to different functions or modules; an application program interface module is used to abstract the sensor application interface through an API function to realize the development of sensor applications; an abstract data encapsulation module realizes the unified description and encapsulation of the data format of the same type of sensors through an abstract data encapsulation method; and a factory automatic registration module uses an abstract class to define the basic structure of the factory, and uses a template method to encapsulate the factory creation process. The development process of sensor applications is simplified, and it is easier to integrate, operate and manage diverse sensor devices, maintaining the high flexibility and adaptability of the system.

Description

Technical Field

[0001] The present invention belongs to the technical field of sensor application development, and in particular relates to a multi-sensor access and data management micro-architecture system of an intelligent controller. Background Art

[0002] Currently, the problems faced by cross-domain heterogeneous autonomous robotic systems involve the diversity and complexity of sensor technologies, as well as challenges related to software and hardware integration. These problems manifest themselves in the following aspects:

[0003] The first is the diversity and differences of sensors: Different robot systems use a variety of different types of sensors, such as cameras, lidar, ultrasonic sensors, inertial measurement units, etc. These sensors are not only different in type, but also have significant differences in data formats and interfaces. This makes it complicated to integrate them into a unified controller platform, and various adaptation and data processing issues need to be solved.

[0004] The second is the structural diversity of robot systems: the structure and shape of robot systems may vary greatly, so when integrating their software and hardware components, adaptation issues need to be solved. Different robots may adopt different structural layouts and power systems, which increases the complexity of integration.

[0005] Finally, there is the challenge of traditional software and hardware integration: traditional software and hardware integration becomes difficult when faced with these differences. Developers usually need to adapt different sensor hardware one by one, which not only increases development costs but also reduces development efficiency.

[0006] In order to meet these challenges, the present invention proposes a concept of a multi-sensor access and data management micro-architecture system of an intelligent controller. Summary of the invention

[0007] In view of the above technical problems, the present invention provides a multi-sensor access and data management micro-architecture system for an intelligent controller.

[0008] The technical solution adopted by the present invention to solve the technical problem is:

[0009] A multi-sensor access and data management micro-architecture system for an intelligent controller, comprising a general processing module, a configuration file parsing module, an application program interface module, an abstract data encapsulation module and a factory automatic registration module;

[0010] The general processing module is used to support system initialization, singleton mode and multi-type data processing;

[0011] The configuration file parsing module is used to receive user configuration instructions to perform targeted configuration on the used sensors, and organize the configuration information in the configuration file according to different functions or modules to transmit relevant parameters of the sensor or enable relevant functions;

[0012] The application program interface module is used to abstract the sensor application interface through API functions to realize the development of sensor applications;

[0013] The abstract data encapsulation module realizes the unified description and encapsulation of the data formats of sensors of the same type through an abstract data encapsulation method based on software definition;

[0014] The factory automatic registration module uses abstract classes to define the basic structure of the factory and uses template methods to encapsulate the factory creation process.

[0015] Preferably, the general processing module includes a system initialization module, a single column template module and a multi-type support module

[0016] The system initialization module defines a class called System, which is used to perform system initialization operations, including configuring core dumps, obtaining the path of the current executable file, and creating a log directory;

[0017] The single column module defines a C++ class called Singleton to create singletons of various classes;

[0018] The multi-type support module defines a C++ class called value to provide generality and flexibility when dealing with different types of data, including configuration file parsing and parameter passing.

[0019] Preferably, the configuration file is in ini format, which is a message configuration document used to store and manage the properties and characteristics of a program. The init format file includes multiple different sections, each section contains multiple key-value pairs, and the configuration items are represented in the form of key values; the configuration information in the configuration file includes:

[0020] Different key values ​​are defined for different sensors. In the configuration file, the Feature configuration section is used to configure the related functions of the middleware. Then the user defines the specific sensor model. There are corresponding parameter configurations under each sensor. The parameter configuration of the specific sensor depends on the sensor model used by the user and its characteristics.

[0021] Preferably, the API function includes an initialization interface function int SmwInit(std::string pathFile), a device handle acquisition interface function DevHandle GetDevice( )、device opening interface function intOpenDevice(DevHandle dev), data acquisition interface function int GetFrameData(DevHandle dev, ) and device closing interface int CloseDevice(DevHandledev);

[0022] int SmwInit(std::string pathFile) is used to initialize SmwAPI. By accepting a string parameter named pathFile, this function allows developers to specify the path of the configuration file required for initialization. The result of initialization is represented by an integer value, where 0 represents successful initialization, while other values ​​reflect possible errors or initialization failures.

[0023] DevHandle GetDevice( ) is used to obtain the handle of the device with the specified name, providing a convenient interface for subsequent device operations; it accepts a name parameter, and by receiving a character pointer type parameter name, the developer specifies the name of the device to be obtained; based on the provided device name, the function will find and locate the corresponding device and return the handle of the device. If the device with the specified name cannot be found or the device does not exist, the function will return a specific error value to prompt the developer of the relevant situation.

[0024] int OpenDevice(DevHandle dev) is used to open a device; it accepts a device handle parameter dev, which identifies the device to be opened. Inside the function, it will try to open the specified device and return an integer value based on the result of the operation. The value is used to indicate the status of the device opening. Returning 0 indicates success, and other values ​​indicate failure to open the device.

[0025] int GetFrameData(DevHandle dev, ) is used to obtain the frame data of the device; it accepts two parameters, the first parameter is the device handle, which is used to identify the device to obtain data, and the second parameter is a pointer to A reference of type, used to store a frame of data obtained from the device; inside the function, it will obtain a frame of data from the specified device and store the obtained data in the passed data container;

[0026] int CloseDevice(DevHandle dev) is used to close the device. It accepts a dev parameter, which is the device handle used to identify the device to be closed. This function closes the device and returns an integer value indicating whether the device is closed successfully.

[0027] Preferably, the abstract data encapsulation module realizes the unified description and encapsulation of the data formats of sensors of the same type through an abstract data encapsulation method based on software definition, including:

[0028] An abstract data encapsulation method based on software definition inherits the data format of all sensors from a unified base class DataBase, including device type, data acquisition frequency, frame number ID, timestamp and device name;

[0029] For different types of sensors, the corresponding data formats are customized and inherited from DataBase. The data formats include ImuData, which is used to uniformly describe the data of inertial measurement units, GpsData, which is used to uniformly describe the data of position sensors, ImageData, which is used to uniformly describe the data of various image sensors, LidarData, which is used to uniformly describe the data of single-line radars, and PowerData, which is used to uniformly describe the data of force / torque sensors.

[0030] Preferably, the factory automatic registration module uses an abstract class to define the basic structure of the factory and encapsulates the factory creation process through a template method, including:

[0031] Design a general sensor abstract class SensorDevice to define the interface provided by all sensors. The abstract class includes four virtual functions as the basic interface of the sensor.

[0032] The abstract factory pattern is introduced. The core of the pattern is the abstract factory class AbstractClassFactory, which inherits from AbstractClassFactoryBase and has two template parameters. One template parameter represents the parent class of the specific sensor, and the other template parameter represents the subclass of the specific sensor. In the abstract factory parent class AbstractClassFactoryBase, two interface functions are defined to obtain the passed-in parent class template name and subclass template name. In the specific abstract factory class AbstractClassFactory, a virtual function named CreateObj() is included. This virtual function will be overridden in the specific sensor factory class to create and return a parent class pointer to the subclass sensor.

[0033] Define a registration macro CLASS_LOADER_REGISTER_CLASS. This macro accepts the names of specific sensor subclasses and parent classes as string parameters in the preprocessing stage, and uses this information to create a sensor factory class. These string parameters are passed to the CreateObj() function, which enables it to dynamically create objects of specific sensor subclasses at runtime. At the same time, these specific factory classes will be saved in a data structure of the unordered_map type in C++ and indexed by key-value pairs.

[0034] Preferably, the four virtual functions include a sensor initialization virtual function bool Initialize(std::string&configPath), a sensor device opening virtual function int OpenDevice(), and an int sensor data acquisition virtual function GetFrameData( ), sensor device close virtual function intCloseDevice();

[0035] bool Initialize(std::string&configPath) is used to read the necessary parameters and settings from the specified configuration file path configPath and use this information to initialize the sensor;

[0036] int OpenDevice() is used to open the sensor device and perform necessary settings after the sensor is successfully initialized to ensure that the sensor is in working condition. The necessary settings include configuring the data transmission mode and other parameters related to the sensor device;

[0037] int GetFrameData( ) is used to obtain a frame of data from the sensor and save it to the passed data array. This array uses the standard C++ container vector, in which each element stores a pointer to the DataBase type;

[0038] int CloseDevice() is used to close the sensor device and release related resources after the sensor operation is completed.

[0039] Preferably, a logger is also included, which is used to output log information of different levels to files and consoles during program execution.

[0040] The multi-sensor access and data management micro-architecture system of the above-mentioned intelligent controller greatly simplifies the complexity of sensor application development. This micro-architecture system is derived from the concept of software defined sensor (SDS), which abstracts the functions, properties, parameters, etc. of various types of sensors into a common software model, and designs a common data structure for efficient transmission of sensor data.

[0041] The multi-sensor access and data management micro-architecture system encapsulates different types of sensors, generates corresponding SDS objects for each sensor, and provides standardized interfaces and services, thereby achieving highly transparent communication between sensors and controllers. This innovative architecture greatly simplifies the development process of sensor applications, allowing developers to more easily integrate, operate and manage diverse sensor devices while maintaining the system's high flexibility and adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 It is a general architecture diagram of a multi-sensor access micro-architecture system in one embodiment of the present invention;

[0043] Figure 2 This is a functional diagram of a general processing module in an embodiment of the present invention;

[0044] Figure 3 A logic diagram of an application interface function call in an embodiment of the present invention;

[0045] Figure 4 This is an operation flow chart of a multi-sensor access micro-architecture system in one embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to enable those skilled in the art to better understand the technical solution of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings.

[0047] In one embodiment, a multi-sensor access and data management micro-architecture system for an intelligent controller includes a general processing module, a configuration file parsing module, an application program interface module, an abstract data encapsulation module, and a factory automatic registration module;

[0048] The general processing module is used to support system initialization, singleton mode and multi-type data processing;

[0049] The configuration file parsing module is used to receive user configuration instructions to perform targeted configuration on the used sensors, and organize the configuration information in the configuration file according to different functions or modules to transmit relevant parameters of the sensor or enable relevant functions;

[0050] The application program interface module is used to abstract the sensor application interface through API functions to realize the development of sensor applications;

[0051] The abstract data encapsulation module realizes the unified description and encapsulation of the data formats of sensors of the same type through an abstract data encapsulation method based on software definition;

[0052] The factory automatic registration module uses abstract classes to define the basic structure of the factory and uses template methods to encapsulate the factory creation process.

[0053] Specifically, the overall architecture of the multi-sensor access and data management micro-architecture system of the above-mentioned intelligent controller is as follows: Figure 1 As shown in the figure, this system is located between the underlying device access and the upper-layer application development, acting as an important middle layer. Its functions include:

[0054] Bottom-level device communication and data exchange: At the bottom level, the software is responsible for communicating and exchanging data with various sensor hardware. This allows different types of sensors to interact with a unified middleware without having to worry about the bottom-level details; and providing a consistent development interface: At the upper level, the multi-sensor access micro-architecture system provides a consistent development interface for application development. Through abstraction technology, it abstracts the bottom-level details of different sensors, allowing developers to focus more on the logic and functionality of the application without having to pay too much attention to the differences in sensors.

[0055] The system has the following features:

[0056] 1. Sensor parameter configuration: Provides flexible sensor parameter configuration function, allowing users to customize sensor properties;

[0057] 2. Unified data output format for similar sensors: Ensure that data from similar sensors are output in a unified format to simplify the data processing process;

[0058] 3. Automatic registration of sensor devices: Supports hot-swap of sensors. The system can automatically identify, configure, manage and access newly added or removed sensors;

[0059] 4. Unified operation interface for multiple sensors: By implementing the template-based automatic registration abstract factory pattern, objects of different sensors are dynamically created and managed, providing a unified operation interface for multiple sensors.

[0060] This micro-architecture system is suitable for heterogeneous autonomous unmanned systems, ensuring the continuous reliability of sensor data, while simplifying the complexity of sensor application development and reducing development and maintenance costs. Developers can more easily integrate, operate and manage diverse sensor devices, thereby developing various applications faster, enabling applications to easily connect sensor hardware with controller upper-level system applications, including autonomous unmanned systems, intelligent monitoring systems, and IoT applications, providing more powerful tools and solutions for various fields. Its main advantages lie in the intelligent multi-sensor access and management functions, as well as the standard processing of sensor data, which improves the flexibility and scalability of the system. This innovative technology is expected to promote the rapid development of autonomous systems and IoT applications in various fields.

[0061] In one embodiment, Figure 2 As shown, the general processing module includes a system initialization module, a single-column template module, and a multi-type support module;

[0062] The system initialization module defines a class called System, which is used to perform system initialization operations, including configuring core dumps, obtaining the path of the current executable file, and creating a log directory;

[0063] The single column module defines a C++ class called Singleton to create singletons of various classes;

[0064] The multi-type support module defines a C++ class named value to provide support for assignment and comparison operations of different data types, including configuration file parsing and parameter passing.

[0065] Specifically, the present invention starts to execute the relevant initialization operations of the system by introducing a general processing module, which includes a system initialization module, a single column module and a multi-type support module.

[0066] The system initialization module implements a class called System to implement tasks such as core dump configuration, obtaining the current execution file path, and creating a log directory. The system initialization module implements a class called System, which is mainly used to perform system initialization operations, including configuring core dumps: ensuring persistent storage of key data and log information to prevent data loss; obtaining the path of the current execution file: when dynamically loading files and resources, it is crucial to ensure the accuracy of the file path, and obtaining the path of the current execution file so that the required files and resources can be correctly referenced; and creating a log directory: creating a log directory helps maintain a clear log file structure and provides effective debugging and troubleshooting support.

[0067] The single column module defines a C++ class named Singleton, which is used to create singletons of various classes. The private attributes of the Singleton class contain a pointer to the template parameter type T, which is used to save the only instance of the class. It declares the default constructor, copy constructor, assignment operator, and destructor as private, effectively ensuring that these functions cannot be directly accessed from the outside, thereby forcing the use of the instance() function to obtain the instance and implement the singleton mode, further strengthening the system initialization function while ensuring the security of the data type.

[0068] In addition, the C++ class named value defined by the multi-type support module also provides support for assignment and comparison operations of different data types, which is mainly used in the following aspects: Configuration file parsing: used to process data of different data types in the configuration file, including strings, integers, and floating-point numbers. This enables the system to easily read and parse various configuration parameters; Parameter passing: The value class can accept different types of data in function parameters, which increases the versatility and flexibility of parameter passing, enables functions to handle multiple data types, improves the reusability and scalability of the code, and enables the system to handle various data types in a flexible manner in various scenarios such as configuration file parsing and parameter passing.

[0069] The general processing modules provide a strong foundation for the present invention, supporting system initialization, singleton mode and multi-type data processing, thereby improving the stability, maintainability and flexibility of the system. The introduction of these modules simplifies the development process, improves the code quality, and brings significant improvements to various heterogeneous system integration and data processing tasks.

[0070] In one embodiment, the configuration file is in ini format, which is a message configuration document used to store and manage the properties and characteristics of a program. The ini format file includes multiple different sections, each section contains multiple key-value pairs, and the configuration items are represented in the form of key values; the configuration information in the configuration file includes:

[0071] Different key values ​​are defined for different sensors. In the configuration file, the Feature configuration section is used to configure the related functions of the middleware. Then the user defines the specific sensor model. There are corresponding parameter configurations under each sensor. The parameter configuration of the specific sensor depends on the sensor model used by the user and its characteristics.

[0072] Specifically, various parameters of the sensor are transmitted in the form of configuration files. Specifically, the present invention adopts the ini (Initialization file) format to define the parameters required for the adaptation of different sensors. The file in the ini format is a message configuration document used to store and manage the properties and characteristics of the program. The structure of the ini file is very intuitive. It consists of multiple different sections. Each section contains multiple key-value pairs, which represent configuration items in the form of key values. This structure allows the user to organize the configuration information according to different functions or modules, making the configuration file clearer and easier to maintain. The user only needs to perform targeted configuration on the sensor to pass the relevant parameters of the sensor or enable related functions.

[0073] Different key values ​​are defined for different sensors. Examples of specific configuration files are as follows:

[0074] [Feature configuration]

[0075] auto_enable=true

[0076] device_type=tty

[0077] [LpmsIG1]

[0078] Serial_port= / dev / ttyUSB0

[0079] baudRate=921600

[0080] [Speed]

[0081] serial_port= / dev / ttyUSB0

[0082] baudRate=9600

[0083] [RealSenseT265]

[0084] Idx=0

[0085] width=640

[0086] Height=480

[0087] In this configuration file, the Feature configuration section is used to configure the related functions of the middleware. auto_enble = true means that the plug-and-play function is enabled, and device_type = tty means that the device type of the sensor is a serial port device (tty). Then the specific sensor model is defined, such as LpmsIG1, Speed, RealSenseT265, etc. This part can be customized by the user, just need to ensure that the sensor model name used in subsequent sensor registration and parsing is consistent. This format makes the configuration of the sensor more flexible and consistent. Developers only need to define the parameters of the sensor through a simple configuration file without having to deeply understand the underlying details of the sensor.

[0088] Each sensor has its corresponding parameter configuration. For example, LpmsIG1 indicates that the device symbol of this sensor is / dev / ttyUSB0 and the baud rate is 921600. Speed ​​indicates that the device symbol of this sensor is / dev / ttyUSB0 and the baud rate is 9600. The image width and height (width, height) listed under the image sensor RealSenseD435, etc., should be noted that the parameter configuration of the specific sensor depends on the sensor model used by the user and its characteristics. This highly configurable approach enables the system to adapt to various types and models of sensors.

[0089] In one embodiment, the API function includes an initialization interface function int SmwInit (std:: stringpathFile), a device handle acquisition interface function DevHandle GetDevice ( )、device opening interface function int OpenDevice(DevHandle dev), data acquisition interface function int GetFrameData(DevHandle dev, ) and device closing interface intCloseDevice(DevHandle dev);

[0090] int SmwInit(std::string pathFile) is used to initialize SmwAPI. By accepting a string parameter named pathFile, this function allows developers to specify the path of the configuration file required for initialization. The result of initialization is represented by an integer value, where 0 represents successful initialization, while other values ​​reflect possible errors or initialization failures.

[0091] DevHandle GetDevice( ) is used to obtain the handle of the device with the specified name, providing a convenient interface for subsequent device operations; it accepts a name parameter, and by receiving a character pointer type parameter name, the developer specifies the name of the device to be obtained; based on the provided device name, the function will find and locate the corresponding device and return the handle of the device. If the device with the specified name cannot be found or the device does not exist, the function will return a specific error value to prompt the developer of the relevant situation.

[0092] int OpenDevice(DevHandle dev) is used to open a device; it accepts a device handle parameter dev, which identifies the device to be opened. Inside the function, it will try to open the specified device and return an integer value based on the result of the operation. The value is used to indicate the status of the device opening. Returning 0 indicates success, and other values ​​indicate failure to open the device.

[0093] int GetFrameData(DevHandle dev, ) is used to obtain the frame data of the device; it accepts two parameters, the first parameter is the device handle, which is used to identify the device to obtain data, and the second parameter is a pointer to A reference of type, used to store a frame of data obtained from the device; inside the function, it will obtain a frame of data from the specified device and store the obtained data in the passed data container;

[0094] int CloseDevice(DevHandle dev) is used to close the device. It accepts a dev parameter, which is the device handle used to identify the device to be closed. This function closes the device and returns an integer value indicating whether the device is closed successfully.

[0095] Specifically, the present invention provides a set of convenient API functions for sensor application developers, and these functions are encapsulated in a namespace called Smw. Application developers only need to master the use of this set of API functions to easily develop sensor applications.

[0096] The present invention abstracts the sensor application interface. Five key interfaces are defined, including the initialization interface function int SmwInit(std::string pathFile), the device handle acquisition interface function DevHandle GetDevice( )、device opening interface function int OpenDevice(DevHandle dev), data acquisition interface function int GetFrameData(DevHandle dev, ) and the device closing interface int CloseDevice(DevHandle dev). These abstract interfaces enable developers to interact with various sensors in a consistent way without worrying about the implementation details of specific sensors.

[0097] Furthermore, the int SmwInit(std::string pathFile) function will call the bool init(std::string&configPath) function, which is responsible for reading the configuration file and performing initialization operations; DevHandle GetDevice( )The implementation mechanism inside this function will call the CreateObj() function to perform the device index operation according to the information pre-stored in the registry. If the device has been registered in the registry, GetDevice will return the device instance of the sensor for further operation and data collection by the developer; intOpenDevice(DevHandle dev)The actual operation of this function is based on the passed dev parameter, calling the OpenDevice() function to actually open the specific sensor device. By providing this function, sensor application developers can easily control and manage the status of sensor devices to ensure that the device is in the correct working state; int GetFrameData(DevHandle dev, )Inside the function, it will get a frame of data from the specified device and store the acquired data in the passed data container. The actual operation of this function is to call GetFrameData( ) function to obtain a frame of sensor data; int CloseDevice(DevHandle dev) This function will call CloseDevice() to release the resources held by the dev device. The calling relationship of the above 5 interface functions is as follows Figure 3 shown.

[0098] In one embodiment, the abstract data encapsulation module implements a unified description and encapsulation of data formats of sensors of the same type through an abstract data encapsulation method based on software definition, including:

[0099] An abstract data encapsulation method based on software definition inherits the data format of all sensors from a unified base class DataBase, including device type, data acquisition frequency, frame number ID, timestamp and device name;

[0100] For different types of sensors, the corresponding data formats are customized and inherited from DataBase. The data formats include ImuData, which is used to uniformly describe the data of inertial measurement units, GpsData, which is used to uniformly describe the data of position sensors, ImageData, which is used to uniformly describe the data of various image sensors, LidarData, which is used to uniformly describe the data of single-line radars, and PowerData, which is used to uniformly describe the data of force / torque sensors.

[0101] Specifically, the multi-sensor access and data management micro-architecture system allows different types of sensors to use the same platform to output data. To achieve this, it is necessary to design a general description method to describe the data format of heterogeneous sensors for transmitting the data information output by the sensors. Common types of sensors include speed sensors, attitude sensors, visual sensors, position sensors, force\torque sensors, etc. There are large differences in the data formats of different types of sensors. In order to be compatible with the data output formats of these sensors, the present invention designs a software-defined abstract data encapsulation method. In this way, the unified description and encapsulation of the data formats of sensors of the same type can be achieved, thereby achieving standardization and normalization of sensor data.

[0102] The data format of the sensor is abstracted. The present invention introduces a unified data format abstraction, so that the data format of all sensors inherits from a common base class Database, and its data structure definition is shown in Table 1. This base class defines the data information that most sensors should contain, while the data format of a specific sensor is defined by derivation. Among them, dataType is defined as the device type, which is used to identify the device type to which the sensor data belongs, such as speed sensor, attitude sensor, etc., frequency is defined as the data acquisition frequency, which is used to record the acquisition frequency of sensor data to determine the speed of data generation, usually in Hertz (Hz), frameId is defined as the frame number ID, which is used to identify the sequence or timestamp of sensor data to ensure the correct sequence and time association of data, timestamp is defined as a timestamp, which is used to record the exact time when the data is generated, providing accurate time information, which is helpful for event recording and time-related analysis, and devName is defined as the device name, which is used to identify the name of the specific device or sensor that generates sensor data, which is helpful for identifying and managing the source of data. This helps to simplify data processing and data exchange, so that various sensor data can be processed consistently.

[0103] Through the abstraction of this base class, the data information that most sensors should have is further defined, providing a common data framework for different types of sensors. The existence of this base class allows the data of different sensors to be described and encapsulated in a consistent manner. Specifically, the data format of each sensor must contain these basic fields to ensure data consistency and processability.

[0104] Table 1 DataBase data structure definition

[0105]

[0106] For different types of sensors, the corresponding data format needs to be customized and inherited from DataBase. The detailed heterogeneous sensor data structure is shown in Table 2. Among them, ImuData is used to uniformly describe the data of the inertial measurement unit, including the measurement values ​​of the accelerometer, gyroscope, magnetometer, etc.; GpsData is used to uniformly describe the data of position sensors such as Beidou and Global Positioning System, including latitude, longitude, altitude and other information; ImageData is used to uniformly describe the data of various image sensors, including image channels, resolution and other information; LidarData is used to uniformly describe single-line radar data, including coordinate system, distance, intensity and other measurement values; PowerData is used to uniformly describe force / torque sensors, including x, y, and z axis forces and torques.

[0107] Table 2 Definition of heterogeneous sensor data structure

[0108]

[0109] In one embodiment, the factory automatic registration module uses an abstract class to define the basic structure of the factory and encapsulates the factory creation process through a template method, including:

[0110] Design a general sensor abstract class SensorDevice to define the interface provided by all sensors. The abstract class includes four virtual functions as the basic interface of the sensor.

[0111] The abstract factory pattern is introduced. The core of the pattern is the abstract factory class AbstractClassFactory, which inherits from AbstractClassFactoryBase and has two template parameters. One template parameter represents the parent class of the specific sensor, and the other template parameter represents the subclass of the specific sensor. In the abstract factory parent class AbstractClassFactoryBase, two interface functions are defined to obtain the passed-in parent class template name and subclass template name. In the specific abstract factory class AbstractClassFactory, a virtual function named CreateObj() is included. This virtual function will be overridden in the specific sensor factory class to create and return a parent class pointer to the subclass sensor.

[0112] Define a registration macro CLASS_LOADER_REGISTER_CLASS. This macro accepts the names of specific sensor subclasses and parent classes as string parameters in the preprocessing stage, and uses this information to create a sensor factory class. These string parameters are passed to the CreateObj() function, which enables it to dynamically create objects of specific sensor subclasses at runtime. At the same time, these specific factory classes will be saved in a data structure of the unordered_map type in C++ and indexed by key-value pairs.

[0113] In one embodiment, the four virtual functions include bool Initialize(std::string&configPath), int OpenDevice(), int GetFrameData( )、intCloseDevice(),

[0114] bool Initialize(std::string&configPath) is used to read the necessary parameters and settings from the specified configuration file path configPath and use this information to initialize the sensor;

[0115] int OpenDevice() is used to open the sensor device and perform necessary settings after the sensor is successfully initialized to ensure that the sensor is in working condition. The necessary settings include configuring the data transmission mode and other parameters related to the sensor device;

[0116] int GetFrameData( ) is used to obtain a frame of data from the sensor and save it to the passed data array. This array uses the standard C++ container vector, in which each element stores a pointer to the DataBase type;

[0117] int CloseDevice() is used to close the sensor device and release related resources after the sensor operation is completed.

[0118] Specifically, the factory automatic registration module adopts an innovative template-based abstract factory pattern, which cleverly combines the template method pattern and the abstract factory pattern, bringing high flexibility and maintainability to the system design. In this design method, the present invention uses C++ to implement the software design pattern of the template-based abstract factory pattern, uses an abstract class to define the basic structure of the factory, and encapsulates the creation process of the factory through the template method. Such a design makes the specific factory subclass only need to pay attention to the implementation of some methods, and entrusts the complex creation logic to the template method of the base class for processing. The design of this module can effectively encapsulate the creation process of the factory and the product, thereby making the entire system more flexible, scalable and easy to maintain.

[0119] When users need to introduce new types of sensor products, there is no need to modify the existing code. It is only necessary to add the corresponding specific product class and specific factory class. This design pattern implements the open-closed principle, and the expansion of the system becomes extremely simple. For example, first of all, the present invention designs a general sensor abstract class SensorDevice, which is used to define the interface provided by all sensors to the outside world. The abstract class includes four virtual functions as the basic interface of the sensor. All specific sensor classes need to inherit from this abstract class and rewrite these virtual functions. At the same time, according to the unique characteristics of the sensor, the required function implementation can be freely added, but it must be ensured that the interface functions defined in the abstract class can be correctly rewritten.

[0120] The virtual functions in these abstract classes are the abstractions of the sensor access interface. Including bool Initialize(std::string&configPath): It is responsible for reading the necessary parameters and settings from the specified configuration file path (configPath) and using this information to initialize the sensor; through this process, the sensor is ready to start working and ensure that it can operate as the user expects. The parameter configPath of this function provides the path of the configuration file for use in the initialization process; int OpenDevice(): Once the sensor is successfully initialized, this function is called, which is responsible for opening the sensor device and making the necessary settings to ensure that the sensor is in working condition, including configuring the data transmission mode and other parameters related to the sensor device. By opening the device, the sensor is ready to receive data and perform corresponding operations; int GetFrameData( ): This function is used to obtain a frame of data from the sensor and save it to the passed data array (data). This array uses the standard C++ container vector, in which each element stores a pointer to the DataBase type. This design allows the storage of multiple types of data and maintains the flexibility of the data organization structure; int CloseDevice(): After the sensor operation is completed, in order to maintain the stability of the system and the rational use of resources, this function is called to close the sensor device and release related resources. This includes operations such as releasing memory and closing device connections to ensure that the sensor can be safely closed and reused.

[0121] In addition, the present invention also introduces an innovative abstract factory pattern to create objects of specific sensor classes more flexibly. The core of this pattern is the abstract factory class AbstractClassFactory, which inherits from AbstractClassFactoryBase and is also a template class with two template parameters. One template parameter represents the parent class of the specific sensor, and the other parameter represents the subclass of the specific sensor. In the abstract factory parent class AbstractClassFactoryBase, two important interface functions are defined to obtain the passed-in parent class template name and subclass template name. These interface functions will play an important role in implementing specific sensor factory classes. In the specific abstract factory class AbstractClassFactory, a virtual function named CreateObj() is included. This virtual function will be overridden in the specific sensor factory class, and its main responsibility is to create and return a parent class pointer pointing to the subclass sensor. This design allows different types of sensor objects to be dynamically created according to user needs without modifying the original code.

[0122] Furthermore, in order to realize the plug-and-play function of the sensor, the present invention uses macro definition to save the creation factory and sensor subclass of each sensor into the data structure of the map class provided by the C++ standard library. Specifically, a registration macro is defined during design: CLASS_LOADER_REGISTER_CLASS, which accepts the name of the specific sensor subclass and parent class as string parameters, and uses this information to create the sensor factory class. These string parameters are passed to the CreateObj() function, so that it can dynamically create objects of specific sensor subclasses at runtime. At the same time, these specific factory classes will be saved in the data structure of unordered_map type in C++ and indexed by key-value pairs. In addition, in order to avoid the problem of repeated registration of the same abstract factory and potential naming conflicts, the designed macro utilizes the characteristics of the internal namespace, static variables and the __COUNTER__ symbol to ensure that each combination of specific sensor subclasses and parent classes will only be registered once. This innovation allows the system to automatically identify and configure newly added or removed sensor devices at runtime to ensure the continuity and reliability of sensor data, while reducing the workload of developers.

[0123] In one embodiment, the system further includes a logger for outputting log information of different levels to files and a console during program execution.

[0124] Specifically, this feature enables users to easily output different levels of log information in the code, which helps with program debugging and troubleshooting.

[0125] The complete user process is as follows Figure 4 As shown, first initialize the configuration - obtain the device instance - connect the sensor - the user turns on the device - obtain data - when the use is finished, turn off the device.

[0126] The multi-sensor access and data management micro-architecture system of the above-mentioned intelligent controller greatly simplifies the complexity of sensor application development. This micro-architecture system is derived from the concept of software defined sensor (SDS), which abstracts the functions, properties, parameters, etc. of various types of sensors into a common software model, and designs a common data structure for efficient transmission of sensor data.

[0127] The multi-sensor access and data management micro-architecture system encapsulates different types of sensors, generates corresponding SDS objects for each sensor, and provides standardized interfaces and services, thereby achieving highly transparent communication between sensors and controllers. This innovative architecture greatly simplifies the development process of sensor applications, allowing developers to more easily integrate, operate and manage diverse sensor devices while maintaining the system's high flexibility and adaptability.

[0128] The above is a detailed introduction to the multi-sensor access and data management micro-architecture system of an intelligent controller provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the core idea of ​​the present invention. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A multi-sensor access and data management micro-architecture system for an intelligent controller, characterized in that: It includes a general processing module, a configuration file parsing module, an application program interface module, an abstract data encapsulation module and a factory automatic registration module; The general processing module is used to support system initialization, singleton mode and multi-type data processing; The configuration file parsing module is used to receive user configuration instructions to perform targeted configuration on the used sensors, and organize the configuration information in the configuration file according to different functions or modules to pass the relevant parameters of the sensor or enable relevant functions; the configuration file is in the ini format, which is a message configuration document used to store and manage the properties and characteristics of the program. The int format file includes multiple different segments, each of which contains multiple key-value pairs, and the configuration items are represented in the form of key values; The application program interface module is used to abstract the sensor application interface through API functions to realize the development of sensor applications; The API functions include the initialization interface function int SmwInit(std::string pathFile), the device handle acquisition interface function DevHandle GetDevice( )、device opening interface function int OpenDevice(DevHandle dev), data acquisition interface function int GetFrameData(DevHandle dev, ) and device closing interface int CloseDevice(DevHandledev); The abstract data encapsulation module realizes the unified description and encapsulation of the data format of the same type of sensors through an abstract data encapsulation method based on software definition, including: an abstract data encapsulation method based on software definition inherits the data format of all sensors from a unified base class DataBase, including device type, data acquisition frequency, frame number ID, timestamp and device name; for different types of sensors, customize their corresponding data formats and inherit from DataBase, wherein the data format includes ImuData for unified description of inertial measurement units, GpsData for unified description of position sensors, ImageData for unified description of various image sensors, LidarData for unified description of single-line radar data, and PowerData for unified description of force / torque sensors; The factory automatic registration module uses abstract classes to define the basic structure of the factory and uses template methods to encapsulate the factory creation process, including: Design a general sensor abstract class SensorDevice to define the interface provided by all sensors. The abstract class includes four virtual functions as the basic interface of the sensor. The abstract factory pattern is introduced. The core of the pattern is the abstract factory class AbstractClassFactory, which inherits from AbstractClassFactoryBase and has two template parameters. One template parameter represents the parent class of the specific sensor, and the other template parameter represents the subclass of the specific sensor. In the abstract factory parent class AbstractClassFactoryBase, two interface functions are defined to obtain the passed-in parent class template name and subclass template name. In the specific abstract factory class AbstractClassFactory, a virtual function named CreateObj() is included. This virtual function will be overridden in the specific sensor factory class to create and return a parent class pointer to the subclass sensor. Define a registration macro CLASS_LOADER_REGISTER_CLASS. This macro accepts the names of specific sensor subclasses and parent classes as string parameters in the preprocessing stage, and uses this information to create a sensor factory class. These string parameters are passed to the CreateObj() function, which enables it to dynamically create objects of specific sensor subclasses at runtime. At the same time, these specific factory classes will be saved in a data structure of the unordered_map type in C++ and indexed by key-value pairs.

2. The system according to claim 1, characterized in that The general processing module includes a system initialization module, a single-column template module, and a multi-type support module; The system initialization module defines a class called System, which is used to perform system initialization operations, including configuring core dumps, obtaining the path of the current executable file, and creating a log directory; The single column module defines a C++ class called Singleton to create singletons of various classes; The multi-type support module defines a C++ class called value to provide generality and flexibility when dealing with different types of data, including configuration file parsing and parameter passing.

3. The system according to claim 1, characterized in that The configuration information in the configuration file includes: Different key values ​​are defined for different sensors. In the configuration file, the Feature configuration section is used to configure the related functions of the middleware. Then the user defines the specific sensor model. There are corresponding parameter configurations under each sensor. The parameter configuration of the specific sensor depends on the sensor model used by the user and its characteristics.

4. The system according to claim 3, characterized in that int SmwInit(std::string pathFile) is used to initialize SmwAPI. By accepting a string parameter named pathFile, this function allows developers to specify the path of the configuration file required for initialization. The result of initialization is represented by an integer value, where 0 represents successful initialization, while other values ​​reflect possible errors or initialization failures. DevHandle GetDevice( ) is used to obtain the handle of the device with the specified name, providing a convenient interface for subsequent device operations; it accepts a name parameter, and by receiving a character pointer type parameter name, the developer specifies the name of the device to be obtained; based on the provided device name, the function will find and locate the corresponding device and return the handle of the device. If the device with the specified name cannot be found or the device does not exist, the function will return a specific error value to prompt the developer of the relevant situation; int OpenDevice(DevHandle dev) is used to open a device; it accepts a device handle parameter dev, which identifies the device to be opened. Inside the function, it will try to open the specified device and return an integer value based on the result of the operation. The value is used to indicate the status of the device opening. Returning 0 indicates success, and other values ​​indicate failure to open the device. int GetFrameData(DevHandle dev, ) is used to obtain the frame data of the device; it accepts two parameters, the first parameter is the device handle, which is used to identify the device to obtain data, and the second parameter is a pointer to >Type reference, used to store a frame of data obtained from the device; inside the function, it will obtain a frame of data from the specified device and store the obtained data in the passed data container; int CloseDevice(DevHandle dev) is used to close the device. It accepts a dev parameter, which is the device handle used to identify the device to be closed. This function closes the device and returns an integer value indicating whether the device is closed successfully.

5. The system according to claim 4, characterized in that The abstract data encapsulation module uses a software-defined abstract data encapsulation method to achieve unified description and encapsulation of data formats of sensors of the same type, including: An abstract data encapsulation method based on software definition inherits the data format of all sensors from a unified base class DataBase, including device type, data acquisition frequency, frame number ID, timestamp and device name; For different types of sensors, the corresponding data formats are customized and inherited from DataBase. The data formats include ImuData, which is used to uniformly describe the data of inertial measurement units, GpsData, which is used to uniformly describe the data of position sensors, ImageData, which is used to uniformly describe the data of various image sensors, LidarData, which is used to uniformly describe the data of single-line radars, and PowerData, which is used to uniformly describe the data of force / torque sensors.

6. The system according to claim 5, characterized in that The four virtual functions include the sensor initialization virtual function boolInitialize(std::string&configPath), the sensor device opening virtual function int OpenDevice(), and the int sensor data acquisition virtual function GetFrameData( ), sensor device close virtual function int CloseDevice(); bool Initialize(std::string &configPath) is used to read the necessary parameters and settings from the specified configuration file path configPath and use this information to initialize the sensor; int OpenDevice() is used to open the sensor device and perform necessary settings after the sensor is successfully initialized to ensure that the sensor is in working condition. The necessary settings include configuring the data transmission mode and other parameters related to the sensor device; int GetFrameData( ) is used to obtain a frame of data from the sensor and save it to the passed data array. This array uses the standard C++ container vector, in which each element stores a pointer to the DataBase type; int CloseDevice() is used to close the sensor device and release related resources after the sensor operation is completed.

7. The system according to claim 1, characterized in that It also includes a logger, which is used to output different levels of log information to files and consoles during program execution.

Images