Embedded software system architecture

By designing an embedded software system architecture, the problems of code complexity and real-time control requirements in the robot control system are solved, and a simpler and more stable system architecture is realized, suitable for omnidirectional mobile robots, and processing I MUs through message channels and timers. Data to ensure system stability and real-time.

CN119105737AInactive Publication Date: 2024-12-10SHENZHEN ADMU INTELLIGENT TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411128669.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-16
Publication Date
2024-12-10
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Technical Problem

In the field of robot control, embedded control systems require real-time control of multiple sensors and actuators, and the code structure is complex and difficult to write.

Method used

Design an embedded software system architecture, including hardware and software levels, including robot controller, upper computer, debugger, supercapacitor, referee system, motor and sensor. The software level connects the application layer, software layer and hardware through message channels. The layer uses independent watchdogs and timers to process I MU data to ensure system stability and real-timeness.

Benefits of technology

The system architecture is simplified, the degree of freedom is improved, and it is suitable for the needs of omnidirectional mobile robots. It also realizes more stable attitude fusion algorithms and data processing through timers and message exchange channels.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119105737A_ABST
    Figure CN119105737A_ABST
Patent Text Reader

Abstract

The invention discloses an embedded software system architecture, which comprises hardware and software, wherein the hardware comprises a robot controller, an upper computer, a debugging machine, a super capacitor controller, a motor, a sensor and a user-defined controller; the controller is respectively connected with the upper computer, the debugging machine, the super capacitor, the judgment system, the motor and sensor and the self-defined controller through codes or interfaces of the controller; the software comprises an application layer, a software layer and a hardware layer, the application layer, the software layer and the hardware layer are all intercommunicated with the message channel, the application layer, the software layer and the hardware layer are connected with the filtering and algorithm library, the application layer is connected with the global state machine, and the hardware layer is connected with the driving layer. According to the invention, the frame is simpler, has higher degree of freedom, and can better meet the actual requirements of the omni-directional mobile robot.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded software, and in particular relates to an embedded software system architecture. Background Art

[0002] Currently in the field of robot control, there are many sensors and actuators that need to be strictly controlled in real time. At the same time, the embedded control system needs to process data from external custom controllers and host computer vision. The code structure is very complex and difficult to write.

[0003] To this end, we propose to prepare an embedded software system architecture to solve the above problems. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide an embedded software system architecture.

[0005] The objective of the present invention is achieved through the following technical solutions:

[0006] An embedded software system architecture, including hardware and software:

[0007] The hardware includes the robot controller, host computer, debugging machine, super capacitor, referee system, motor and sensor, and custom controller. The controller is connected to the host computer, debugging machine, super capacitor, referee system, motor and sensor, and custom controller through its own code or interface.

[0008] The software includes application layer, software layer and hardware layer. The application layer, software layer and hardware layer are all interconnected with the message channel. The application layer, software layer and hardware layer are connected to the filter and algorithm library. The application layer is connected to the global state machine, and the hardware layer is connected to the driver layer.

[0009] Furthermore, the application layer and the hardware layer are each equipped with an independent watchdog, which is fed after the gyroscope module is triggered by the timer to process the IMU data, while the software watchdog is completed by the CAN sending task in the RTOS.

[0010] Furthermore, the individual modules of the application layer, software layer, and hardware layer adopt a relatively fixed method and must include init and update functions, wherein init includes all the processes required for module startup, and the update function includes the daily necessary operations required for the normal operation of the module and the update of the module's own status and data.

[0011] Furthermore, in the processing of the IMU data, time alignment is very important. The update interrupt generated by the timer can make the attitude fusion algorithm run more stably. At the same time, the accumulation operation with us granularity is generated by the timer to obtain the time elapsed in the IMU data update, so that when integrating the acceleration, the data delay can be effectively compensated to obtain more stable gyroscope data. The data generated by the IMU is completed through the message exchange channel, which also includes data exchange of other modules. The connection between different modules at different levels is decoupled here.

[0012] Compared with the prior art, the present invention has the following beneficial effects:

[0013] The framework of the present invention is simpler, has a higher degree of freedom, and is more in line with the actual needs of the omnidirectional mobile robot. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 It is the hardware connection diagram of the present invention;

[0015] Figure 2 This is a software architecture diagram of the present invention;

[0016] Figure 3 Execute the flow chart for the init and update functions. DETAILED DESCRIPTION

[0017] The following will describe the implementation methods of the present application in detail with the help of accompanying drawings and examples, so that the implementation process of how the present application uses technical means to solve technical problems and achieve technical effects can be fully understood and implemented accordingly.

[0018] An embedded software system architecture hardware and software:

[0019] The hardware includes robot controller, host computer, debugging machine, super capacitor, referee system, motor and sensor, custom controller. The controller is connected to the host computer, debugging machine, super capacitor, motor and sensor, custom controller through its own code or interface. The embedded system architecture is designed as a customized solution for a single robot control panel. Conventional hardware connections are as follows: Figure 1 As shown;

[0020] The software includes the application layer, software layer, and hardware layer. The application layer, software layer, and hardware layer are all interconnected with the message channel. All modules mainly use the message exchange channel as an important module interaction method, which ensures the stability and real-time performance of message exchange. The application layer, software layer, and hardware layer are connected to the filter and algorithm library, the application layer is connected to the global state machine, and the hardware layer is connected to the driver layer.

[0021] In terms of software architecture, the single principle is adopted. Each module only relies on its own code or interface, as well as its lower-level interface. It is only responsible for its own functions and cannot reversely call the upper-level interface. When the lower-level module cannot meet the needs of the upper-level module, it is rewritten or new functions are added to the module, exposing new interfaces. The overall structure is as follows: Figure 2 shown.

[0022] The advantage of doing this is that when a certain function needs to be modified (for example, the control parameters of the gimbal by the auto-aiming system), apart from the auto-aiming code at the application layer, there will definitely be no other places where the auto-aiming will interfere with other components.

[0023] like Figure 3 As shown in the figure, the design of a single module adopts a relatively fixed approach, which must include init and update functions. Init includes all the processes required for module startup, and the update function includes the daily necessary operations required for the normal operation of the module and the update of the module's own status and data. Therefore, the update function will be executed regularly in the RTOS. The benefits of this approach are obvious. If we are concerned about the main behavior and status data of the module's operation, we only need to check the update function; if we need to modify the module's own parameters, we only need to care about the init function. For related functions of other modules, they exist in the style of interface functions.

[0024] In addition, for the stability of the system and to prevent unexpected crashes, both watchdogs are enabled. The independent watchdog is fed after the gyroscope module is triggered by the timer and processes the IMU data. The software watchdog is completed by the CAN sending task in the RTOS. If special circumstances occur (such as static electricity interfering with the CAN or the robot arm is at an unexpected angle), the operator can restart the CAN peripheral or hard restart the control board by pressing five different keys at the same time.

[0025] In addition to preventing accidental crashes, time alignment is very important for the processing of IMU data. The update interrupt generated by the timer can make the attitude fusion algorithm run more stably. At the same time, the accumulation operation of us granularity is generated by the timer to obtain the time elapsed in the IMU data update, so that when integrating the acceleration, the data delay can be effectively compensated to obtain more stable gyroscope data. The data generated by IMU is completed through the message exchange channel, which also includes the data exchange of other modules. The connection between different modules at different levels is decoupled here.

[0026] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the present invention in any form. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention fall within the protection scope of the present invention.

[0027] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any simple modification, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention are within the scope of the technical solution of the present invention.

Claims

1. An embedded software system architecture, characterized in that: Includes hardware and software: The hardware includes a robot controller, a host computer, a debugging machine, a super capacitor, a motor and a sensor, and a custom controller. The controller is connected to the host computer, the debugging machine, the super capacitor, the motor and a sensor, and the custom controller through its own code or interface. The software includes application layer, software layer and hardware layer. The application layer, software layer and hardware layer are all interconnected with the message channel. The application layer, software layer and hardware layer are connected to the filter and algorithm library. The application layer is connected to the global state machine, and the hardware layer is connected to the driver layer.

2. The embedded software system architecture according to claim 1, characterized in that: The application layer and the hardware layer are both equipped with an independent watchdog, which is fed after the gyroscope module is triggered by the timer to process the IMU data, while the software watchdog is completed by the CAN sending task in the RTOS.

3. The embedded software system architecture according to claim 1, characterized in that: The individual modules of the application layer, software layer, and hardware layer adopt relatively fixed methods and must include init and update functions, where init includes all the processes required for module startup, and the update function includes the daily necessary operations required for the normal operation of the module and the update of the module's own status and data.

4. The embedded software system architecture according to claim 2, characterized in that: In the processing of the IMU data, time alignment is very important. The update interrupt generated by the timer can make the attitude fusion algorithm run more stably. At the same time, the timer generates an accumulation operation with a granularity of us to obtain the time elapsed in the IMU data update, so that when integrating the acceleration, it can effectively compensate for the data delay and obtain more stable gyroscope data. The data generated by the IMU is completed through the message exchange channel, which also includes data exchange of other modules. The connection between different modules at different levels is decoupled here.