DDS (Direct Digital Synthesizer)-based data flow driven robot state lamp strip self-adaptive display system and method

Abstract

The invention discloses a DDS-based data flow driven robot state lamp strip adaptive display system and method, and relates to the technical field of robot intelligent interaction and state visual monitoring, and the system comprises a state publishing module, communication middleware, a lamp strip arbitration module and lamp strip hardware; the state issuing module comprises a plurality of function modules, and the function modules are a system monitoring module, a motion control module and an upper-layer application program module in the robot main control system. According to the DDS-based data flow driven robot state lamp strip adaptive display system and method, systematic innovation of robot state lamp strip display is realized through a distributed architecture and an intelligent arbitration mechanism based on data distribution service. According to the system, the problem of multi-module display conflicts is effectively solved, important states are ensured to be presented preferentially through priority dynamic arbitration, and system resource use is optimized while animation fluency is ensured in combination with an adaptive frequency control mechanism.

Description

Technical Field

[0001] This invention relates to the field of robot intelligent interaction and status visualization monitoring technology, specifically to a robot status light strip adaptive display system and method based on DDS data stream driven. Background Technology

[0002] Currently, robot status displays primarily rely on screen information, voice prompts, or simple LED indicators. However, these methods have significant limitations: screens require active user reading and understanding, voice prompts are prone to failure in noisy environments, and simple LEDs cannot convey rich and specific status information, such as different fault types. For robots using RGB LED strips, existing control methods often involve the main control program directly calling the underlying hardware interface to drive the LED strip, resulting in a high degree of coupling between status display logic and business logic. This coupled architecture raises a core problem: the lack of a unified coordination mechanism. When multiple functional modules, such as system monitoring, motion control, and applications, simultaneously control the LED strip, they cannot intelligently arbitrate display priorities. Important states, such as emergency faults, are easily overridden by secondary states, such as standby animations, thus misleading users. Furthermore, this architecture has poor scalability; adding new display effects requires modification of the main control code, making it difficult to support user-defined development. Moreover, frequent system resource conflicts occur, with modules potentially refreshing data at excessively high frequencies, unnecessarily consuming bus bandwidth and CPU resources, affecting the real-time performance of the robot's core business. Therefore, there is an urgent need for an adaptive LED strip control solution that can decouple display from business logic and achieve intelligent priority arbitration and resource optimization. Summary of the Invention

[0003] The purpose of this invention is to provide a robot status light strip adaptive display system and method based on DDS data stream driven, so as to solve the problems mentioned in the background art.

[0004] To solve the above technical problems, the present invention provides the following technical solution: a robot status light strip adaptive display system and method based on DDS data stream driven, including: a status release module, a communication middleware, a light strip arbitration module, and light strip hardware;

[0005] The status publishing module includes multiple functional modules, namely the system monitoring module, motion control module, and upper-layer application module in the robot main control system. Each functional module independently generates LED strip control data corresponding to the robot's status based on its own business logic. The LED strip control data includes a pixel color array, a priority field, and a mode identifier. As a publisher of the data distribution service, the functional module publishes a continuous stream of LED strip control messages to a unified data distribution service topic through the communication middleware. The pixel color array adopts a dynamically lengthed vector queue data structure, and the length of the vector queue is dynamically determined at runtime based on the number of pixels in the LED strip hardware.

[0006] The communication middleware is a data distribution service domain, responsible for transmitting the light strip control messages between the status publishing module and the light strip arbitration module, ensuring reliable message distribution. The light strip arbitration module, as the sole subscriber to the data distribution service topic, continuously receives light strip control message streams from all functional modules. The light strip arbitration module internally maintains a priority mapping table, which presets priority values ​​for each known robot state mode. Based on the priority field in the received messages and the priority mapping table, the light strip arbitration module compares the priorities of all messages in real time and selects the pixel data corresponding to the message with the highest priority as a candidate output frame. The light strip arbitration module also sets a fixed output frame rate, down-processing high-frequency messages and buffering low-frequency messages to maintain continuous output, ensuring smooth light strip animation display. The light strip arbitration module also includes a timing mechanism, reserving a fixed time window for specific system-level states. If a system-level alarm state exists within the time window, a preset light strip effect is forcibly output.

[0007] The light strip hardware includes a microcontroller and an RGB light strip. The microcontroller receives the final output instruction from the light strip arbitration module and drives the RGB light strip to display dynamic or static effects defined by the corresponding pixel color array. The light strip arbitration module achieves priority arbitration, resource optimization, and reliability assurance for robot status display through the coordinated action of the priority mapping table, fixed output frame rate setting, frame buffering mechanism, and timing mechanism.

[0008] Furthermore, the process by which each functional module in the status release module independently generates LED strip control data includes: calculating the color value sequence of the corresponding LED strip pixels based on the real-time status changes of the robot, and encapsulating the color value sequence into a vector queue; the length of the vector queue is consistent with the number of hardware pixels of the target LED strip, the priority field is dynamically assigned according to the importance of the status, and the pattern identifier is used to identify the status type during the arbitration process.

[0009] Furthermore, the priority arbitration process of the light strip arbitration module includes:

[0010] Continuously monitor the message stream incoming from the data distribution service topic;

[0011] Parse the priority field and pattern identifier of each message;

[0012] Query the priority mapping table in the internal storage to obtain the priority value of the corresponding state mode;

[0013] Compare the priority values ​​of all active messages and select the pixel data corresponding to the message with the highest priority value as the current candidate output frame;

[0014] The priority mapping table supports dynamic updates, allowing the addition, modification, or deletion of status modes and their priority settings through the configuration interface.

[0015] Furthermore, the frequency control and flow smoothing mechanism of the LED strip arbitration module includes:

[0016] Set a fixed output frame rate that is lower than the saturation threshold of the robot's main control system bus bandwidth;

[0017] For message sources whose release frequency is higher than the fixed output frame rate, a frame dropping or interpolation algorithm is used to reduce the frequency so that the output frame rate matches the set value.

[0018] For message sources whose publishing frequency is lower than the fixed output frame rate, the pixel data is cached after a new message is received, and the cached last frame of valid data is repeatedly output in subsequent output cycles until a new message arrives.

[0019] By managing frame data from different message sources through a frame buffer queue, the continuity and smoothness of the output data are ensured.

[0020] Furthermore, the timing mechanism of the light strip arbitration module is a system-level status forced display window, which is implemented in the following ways:

[0021] A high-priority timer is embedded in the arbitration logic, and the timer is assigned a fixed display time window for a specific system-level state.

[0022] When the system monitoring module issues a system-level alarm status, the timer is triggered and the forced display window is activated;

[0023] During the forced display window, the LED strip arbitration module pauses the regular priority arbitration process and directly outputs the preset alarm LED strip effect;

[0024] After the forced display window ends, the LED strip arbitration module automatically resumes the normal arbitration process and selects the message with the highest priority for output.

[0025] Furthermore, the hardware abstraction design of the LED strip arbitration module is implemented through a dynamic vector queue, including:

[0026] The vector queue serves as the carrier of the pixel color array in the data distribution service message, and its length is dynamically allocated at runtime based on the actual number of LED strip pixels.

[0027] The microcontroller is configured to parse a variable-length vector queue and drive a corresponding number of RGB LEDs;

[0028] When replacing the LED strip hardware with different pixel counts, only the pixel count parameter of the microcontroller needs to be adjusted, and all status publishing modules automatically adapt to the new length of the sending vector queue without modifying the software architecture.

[0029] Furthermore, the system supports secondary development by users through the publishing interface of the open data distribution service topic; user-defined applications only need to follow the unified message format and publish pixel data frames to the data distribution service topic to achieve custom light strip animation effects without modifying the light strip arbitration module and the underlying driver code.

[0030] Furthermore, the LED strip arbitration module also includes a state persistence mechanism, which can load the last known valid state and priority mapping table from persistent storage after system restart or abnormal recovery, ensuring the continuity of display behavior.

[0031] Furthermore, the system configures the reliability and real-time performance of message transmission through the service quality policy of the data distribution service, and sets different service quality levels for different status messages to ensure low-latency transmission of high-priority status messages.

[0032] An adaptive display method for robot status LED strips based on data distribution services and data streams, applied to the DDS-based data stream-driven adaptive display system for robot status LED strips, includes the following steps:

[0033] S1: The light strip control data corresponding to the robot state is generated independently by multiple functional modules. The light strip control data includes a pixel color array, a priority field, and a mode identifier.

[0034] S2: Publish the light strip control data as a continuous message stream to a unified topic through the data distribution service domain;

[0035] S3: Subscribe to the unified topic through the LED strip arbitration module, receive all message streams, and select the pixel data corresponding to the message with the highest priority as the candidate output frame in real time based on the priority mapping table;

[0036] S4: Set a fixed output frame rate through the LED strip arbitration module, reduce the frequency of high-frequency messages, and buffer the frames of low-frequency messages to ensure smooth output;

[0037] S5: Through the timing mechanism of the LED strip arbitration module, a preset LED strip effect is forcibly output when the system-level state is triggered;

[0038] S6: The microcontroller parses the final output instructions and drives the RGB light strip to display the corresponding effects.

[0039] This invention provides a robot status light strip adaptive display system and method based on DDS data stream driven by DDS. It has the following beneficial effects:

[0040] This DDS-based dataflow-driven adaptive display system and method for robot status LED strips achieves a systemic innovation in robot status LED strip display through a distributed architecture based on data distribution services and an intelligent arbitration mechanism. The system effectively solves the problem of multi-module display conflicts, ensuring that important states are presented first through dynamic priority arbitration, and optimizing system resource utilization while maintaining animation smoothness through an adaptive frequency control mechanism. Its dataflow-driven mode completely decouples state generation from display output, and, combined with hardware abstraction design, achieves seamless compatibility with LED strips of different specifications.

[0041] This DDS-based dataflow-driven adaptive display system and method for robot status LED strips provides a reliable system-level status protection mechanism, ensuring the immediate visibility of critical alarm states through a forced display window. Open secondary development interfaces allow users to flexibly customize display effects, while status persistence enhances the system's fault tolerance and recovery capabilities. These features together constitute a robot status display solution that meets real-time requirements and possesses good scalability, improving the intuitiveness and reliability of human-machine interaction. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the interaction of the robot status light strip adaptive display system module driven by DDS data stream according to the present invention;

[0043] Figure 2 This is a flowchart of the frequency control mechanism of the DDS-based data stream-driven adaptive display system for robot status LED strips according to the present invention.

[0044] Figure 3 This is a service quality strategy configuration diagram for the DDS-based data stream-driven adaptive display system for robot status LED strips according to the present invention. Detailed Implementation

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

[0046] Please see Figures 1 to 3 The present invention provides a technical solution: a robot status light strip adaptive display system and method based on DDS data stream driven, including: a status release module, a communication middleware, a light strip arbitration module and light strip hardware;

[0047] The status publishing module includes multiple functional modules, namely the system monitoring module, motion control module, and upper-layer application module in the robot's main control system. Each functional module independently generates LED strip control data corresponding to the robot's status based on its own business logic. The LED strip control data includes a pixel color array, a priority field, and a mode identifier. As a publisher of the data distribution service, the functional module publishes a continuous stream of LED strip control messages to a unified data distribution service topic through communication middleware. The pixel color array adopts a dynamically long vector queue data structure, and the length of the vector queue is dynamically determined at runtime based on the number of pixels in the LED strip hardware.

[0048] The communication middleware serves as the data distribution service domain, responsible for transmitting LED strip control messages between the status publishing module and the LED strip arbitration module, ensuring reliable message distribution. The LED strip arbitration module, as the sole subscriber to the data distribution service topic, continuously receives LED strip control message streams from all functional modules. Internally, the LED strip arbitration module maintains a priority mapping table, which presets priority values ​​for each known robot state mode. Based on the priority field in the received messages and the priority mapping table, the LED strip arbitration module compares the priorities of all messages in real time and selects the pixel data corresponding to the message with the highest priority as the candidate output frame. The LED strip arbitration module also sets a fixed output frame rate, down-processing high-frequency messages and buffering low-frequency messages to maintain continuous output, ensuring smooth LED strip animation display. Furthermore, the LED strip arbitration module includes a timing mechanism that reserves a fixed time window for specific system-level states; if a system-level alarm state exists within the time window, the preset LED strip effect is forcibly output.

[0049] The LED strip hardware includes a microcontroller and an RGB LED strip. The microcontroller receives the final output command from the LED strip arbitration module and drives the RGB LED strip to display dynamic or static effects defined by the corresponding pixel color array. The LED strip arbitration module achieves priority arbitration, resource optimization, and reliability assurance for robot status display through the coordinated action of a priority mapping table, fixed output frame rate setting, frame buffering mechanism, and timing mechanism.

[0050] It should be further explained that the system achieves adaptive display of the robot's status light strip by constructing an intelligent arbitration architecture with a dual screening mechanism based on a data distribution service for communication. In specific implementation, each functional module in the status release module, including the system monitoring module, motion control module, and upper-level application module, independently generates light strip control data containing pixel color arrays, priority fields, and pattern identifiers based on the robot's real-time operating status.

[0051] The pixel color array employs a dynamically lengthened vector queue structure, the length of which is dynamically determined at runtime based on the actual number of connected LED strip pixels. This design decouples the system from hardware specifications at the protocol level. Each functional module acts as a DDS publisher, continuously publishing LED strip control message flows through a unified DDS topic.

[0052] The LED strip arbitration module, as the sole subscriber to this topic, maintains a configurable priority mapping table to preset priority values ​​for each known state mode. Its core implementation lies in a dual screening mechanism: First, it performs a real-time screening of the continuously received message stream by parsing the priority field in the message and querying the priority mapping table to dynamically compare the priorities of all active messages, always selecting the pixel data corresponding to the message with the highest priority as the candidate output frame. Then, a second screening is performed by setting a fixed output frame rate to down-convert high-frequency messages and buffering low-frequency messages to maintain continuous output. Simultaneously, an embedded timer establishes a forced display window for system-level states. When a system-level alarm state is detected, the regular arbitration process is immediately interrupted, and a preset alarm effect is forcibly output within a fixed time window.

[0053] The pixel data, determined through a double screening process, is then displayed using a microcontroller-driven RGB LED strip hardware. This implementation scheme ensures reliable display of critical states and rational allocation of system resources through the synergistic effect of dynamic priority contention arbitration, frequency smoothing, and forced window verification. Furthermore, leveraging the DDS communication architecture and dynamic vector queue design, it achieves complete decoupling between software and hardware, and enables user-defined expansion capabilities.

[0054] The process by which each functional module in the status release module independently generates LED strip control data includes: calculating the color value sequence of the corresponding LED strip pixels based on the robot's real-time status changes, and encapsulating the color value sequence into a vector queue; the length of the vector queue is consistent with the number of hardware pixels of the target LED strip, the priority field is dynamically assigned according to the importance of the status, and the pattern identifier is used to identify the status type during the arbitration process.

[0055] It should be further explained that the process of each functional module in the status release module independently generating light strip control data includes: each module calculates the color value sequence of the corresponding light strip pixels based on the robot's real-time status changes using the built-in color mapping algorithm;

[0056] The color mapping algorithm described above is implemented in two ways, depending on the robot's state type: static preset mapping and dynamic parameter mapping, as detailed below:

[0057] The specific implementation of the color mapping algorithm: In this embodiment, the color mapping algorithm is divided into two methods: static preset mapping and dynamic parameter mapping, covering the display requirements of different robot states, specifically including the following:

[0058] Static preset mapping, i.e., fixed state-color correspondence: For the robot's core fixed states, a preset "state-color-pattern identifier" mapping table is provided, as shown in the table below:

[0059] Robot status Pattern identifier RGB color values: 0-255 LED strip display effect The system is running normally. STATE_NORMAL (0，255，0) All LED strip lights are always on in green. System overload alarm ALARM_OVERLOAD (255，0，0) Full LED strip high-frequency flashing (1Hz) red Motion malfunction (such as jamming) ALARM_MOTION (255，165，0) The light strip gradually turns orange from both ends towards the middle. Low battery (≤20%) ALARM_LOW_POWER (255，255，0) The LED strip emits a slow, breathing yellow light (0.5Hz). Task in progress STATE_TASK_RUN (0，0，255) The light strip runs from left to right with blue lights. standby mode STATE_STANDBY (128，0，128) The entire LED strip is constantly lit in low brightness (50%) purple. Custom animation (user) USER_CUSTOM Custom RGB values Data displayed by user pixels

[0060] Dynamic parameter mapping, i.e., color calculation based on state parameters: For states that need to change with parameters (such as battery level, task progress), a parameter-color component linear mapping algorithm is used. Taking "battery level" as an example:

[0061] Define input parameter: remaining battery percentage P, 0% ≤ P ≤ 100%;

[0062] Set RGB component mapping rules:

[0063] Green component G: Decreases linearly with P, G=floor(P×2.55), G=255 when P=100%, and G=0 when P=0%;

[0064] The red component R increases linearly with P, R = floor, (100-P)×2.55), R = 0 when P = 100%, and R = 255 when P = 0%.

[0065] Blue component B: Fixed at 0;

[0066] Calculation example: When =50%, G=50×2.55=127.5→128, R=(100-50)×2.55=127.5→128, that is, RGB(128, 128, 0) (yellow);

[0067] When P=30%, G=30×2.55=76.5→77, R=70×2.55=178.5→179, that is, RGB(179,77,0) (orange-yellow);

[0068] LED strip display effect: As the battery level decreases, the color gradually transitions from green to yellow, orange-yellow, and red, intuitively reflecting the change in battery level.

[0069] The color mapping execution process includes the following:

[0070] When the functional module generates LED strip control data, it first selects either "static preset" or "dynamic parameter" mapping method according to the status type.

[0071] If it is a static state, the RGB value is obtained by directly querying the mapping table; if it is a dynamic state, the RGB value is calculated by inputting parameters and using a formula.

[0072] Assemble the RGB values ​​into a vector queue according to the number of pixels in the light strip. For example, for a 100-pixel light strip, generate a vector queue of 100 RGB values.

[0073] Encapsulate the vector queue, priority field, and pattern identifier into a light strip control message and publish it to the DDS topic.

[0074] The algorithm dynamically generates RGB primary color values ​​based on state type and state parameters, and assembles these values ​​into a complete color data sequence according to the pixel order of the LED strip. The color value sequence is then encapsulated into a dynamically long vector queue data structure. The vector queue is allocated in memory using a contiguous storage method, and its length is dynamically determined at runtime by querying the configuration parameters of the connected LED strip hardware, thereby achieving automatic adaptation to LED strip hardware with different pixel counts.

[0075] During the data encapsulation process, each functional module dynamically assigns a priority field value according to a predefined status importance assessment rule. This assessment rule comprehensively considers the urgency of the status, the security level, and business logic requirements, and calculates the final priority value through weight calculation. At the same time, the module also attaches a pattern identifier to each message. This identifier is defined using an enumeration type and is used to quickly identify and classify different status types during the arbitration process.

[0076] It should be further explained that the above-mentioned 'state importance assessment rule' achieves dynamic assignment of the priority field through a multi-dimensional quantization-weighted summation algorithm. The specific steps are as follows:

[0077] The specific implementation of the priority assignment algorithm is as follows: In this embodiment, the dynamic assignment of the priority field is achieved through a multi-dimensional quantization-weighted summation algorithm, and the specific steps are as follows:

[0078] The quantitative standards are defined as follows: Quantifiable grading standards and corresponding scores are set for the three evaluation dimensions of "urgency," "security level," and "business logic requirements," as shown in the table below:

[0079] Evaluation Dimensions Grading Standards Corresponding score: 0-10 points illustrate urgency Emergency alerts (such as system overload) 10 Immediate intervention is required; otherwise, it will affect the robot's operation. Critical conditions (such as motion failure) 8 It affects local function and needs to be dealt with promptly. Normal state (such as task execution) 5 Normal business process, no urgent risks. Secondary states (such as standby animations) 2 This is only for interactive prompts and does not affect functionality. Security level Safety risks (such as collision warnings) 10 This could lead to equipment damage or personnel safety risks. Safety concerns (such as low battery) 7 No immediate risk, but attention is needed. Safety not involved (as per normal display) 3 No security-related logic involved Business logic requirements Core business (such as motion control) 8 Corresponding to the robot's core function execution status Ancillary services (such as data collection) 5 Supports core business, not essential Non-business-related (such as custom animations) 2 No business connection, only user interaction needs

[0080] The weighting and calculation methods are as follows:

[0081] The weighting ratios for each dimension are set as follows: Urgency (50%) > Security Level (30%) > Business Logic Requirements (20%). The final priority score is calculated using the following formula: Priority Score = (Urgency Score × 0.5) + (Security Level Score × 0.3) + (Business Logic Requirements Score × 0.2). The calculation result is rounded to the nearest integer. If the results are the same, the state with the higher "Urgency" score will be given higher priority by default.

[0082] An application example is as follows: When the system monitoring module detects "system overload," i.e., urgency 10 points, security level 10 points, business logic requirement 8 points, the priority score is: 10×0.5+10×0.3+8×0.2=5+3+1.6=9.6, rounded down to 10; when the upper-layer application module publishes "standby animation," i.e. urgency 2 points, security level 3 points, business logic requirement 2 points, the priority score is: 2×0.5+3×0.3+2×0.2=1+0.9+0.4=2.3, rounded down to 2;

[0083] The system automatically selects the light strip control data corresponding to the "system overload" state with higher priority score as the candidate output frame.

[0084] The entire data generation process is executed in independent threads of each module, and the real-time calculation and publication of status data is achieved through asynchronous non-blocking, ensuring that the core business logic of the robot's main control system is not blocked. This data generation mechanism based on dynamic vector queues and real-time priority calculation enables the system to flexibly adapt to different specifications of LED strip hardware, while ensuring that important states are displayed in a timely and accurate manner through fine-grained priority management.

[0085] The priority arbitration process of the LED strip arbitration module includes:

[0086] Continuously monitor the message stream incoming from the data distribution service topic;

[0087] Parse the priority field and pattern identifier of each message;

[0088] Query the priority mapping table in the internal storage to obtain the priority value of the corresponding state mode;

[0089] Compare the priority values ​​of all active messages and select the pixel data corresponding to the message with the highest priority value as the current candidate output frame;

[0090] The priority mapping table supports dynamic updates, allowing the addition, modification, or deletion of status modes and their priority settings through the configuration interface.

[0091] It should be further explained that the priority arbitration process of the light strip arbitration module is implemented by establishing a multi-level message processing pipeline. This pipeline first continuously listens to the message stream of the specified topic through the DDS subscription interface, and performs format verification and integrity verification on each received message.

[0092] During the parsing phase, the arbitration module extracts the priority field and pattern identifier from the message header. The priority field is an integer value, and the pattern identifier is represented by a string hash value. Then, it obtains the base priority of the corresponding state pattern by querying the internally maintained priority mapping table. This mapping table is stored using a hash table data structure, with the pattern identifier as the key and the base priority value as the value.

[0093] During the comparison and selection phase, the arbitration module maintains an active message buffer and performs real-time priority comparison on all verified messages. By maintaining the index pointer of the current highest priority message, the pointer is updated every time a new message arrives, ensuring that the pixel data corresponding to the message with the highest priority value is always selected as the candidate output frame.

[0094] The priority mapping table supports dynamic updates via a configuration interface, which provides add, modify, and delete operations. When the system needs to add a new state mode or adjust the priority, the update method of the configuration interface is called, passing in the mode identifier and the new priority value. The system will complete the atomic update of the mapping table while ensuring thread safety, and at the same time trigger the re-initialization of the arbitration logic to ensure a smooth transition of state switching.

[0095] The entire arbitration process adopts an event-driven mechanism. Arbitration calculation is triggered immediately when a new message or mapping table update event is received, and data consistency in a multi-threaded environment is guaranteed by a mutex lock mechanism. This dynamically configurable priority arbitration mechanism enables the system to flexibly adapt to the status display requirements of different application scenarios, while ensuring timely response and reliable display of high-priority status information.

[0096] The frequency control and flow smoothing mechanism of the LED strip arbitration module includes:

[0097] Set a fixed output frame rate that is lower than the saturation threshold of the robot's main control system bus bandwidth;

[0098] For message sources whose release frequency is higher than the fixed output frame rate, frame dropping or interpolation algorithms are used to reduce the frequency so that the output frame rate matches the set value.

[0099] For message sources that publish at a frequency lower than the fixed output frame rate, their pixel data is cached after a new message is received, and the cached last frame of valid data is repeatedly output in subsequent output cycles until a new message arrives.

[0100] By managing frame data from different message sources through a frame buffer queue, the continuity and smoothness of the output data are ensured.

[0101] It should be further explained that the frequency control and flow smoothing mechanism of the LED strip arbitration module is achieved by constructing a multi-level frame rate adjustment system. This system first sets a fixed output frame rate, the value of which is determined based on the available bandwidth of the robot system bus and the processor's computing power. Its specific value is lower than the threshold that may cause bus saturation but higher than the minimum threshold that the human eye can perceive as stuttering.

[0102] For high-frequency message sources whose release frequency is higher than the set fixed output frame rate, the system uses a selective frame discarding algorithm for processing. This algorithm is based on the time window to count the message arrival frequency. While maintaining a stable output frame rate, it retains key animation frames at equal intervals. At the same time, for scenes that need to maintain animation continuity, a linear interpolation algorithm is used to generate transition frames between adjacent frames.

[0103] For low-frequency message sources whose output frequency is lower than the set fixed output frame rate, the system establishes a frame buffer management mechanism. This mechanism immediately stores the pixel data of a new message into a circular buffer after receiving it, and repeatedly reads the last frame of valid data in the buffer for output in each subsequent output cycle until a new message arrives and updates the buffer content.

[0104] The system manages frame data from different message sources through a unified frame buffer queue. This queue adopts a dual index structure of priority and time order to ensure that the continuity and smoothness of output data can still be maintained in a mixed message source environment.

[0105] It should be further explained that, in order to clarify the specific execution logic of the above-mentioned frequency control and flow smoothing mechanism, this embodiment further defines the fixed output frame rate setting, the frame dropping rules for high-frequency messages, the interpolation algorithm for smooth transition, and the frame buffering rules for low-frequency messages, as specifically implemented as follows:

[0106] The specific implementation of the frequency reduction and interpolation algorithm is as follows:

[0107] The fixed output frame rate setting, including in this embodiment, is set to 30 fps. This frame rate is lower than the saturation threshold of the bus bandwidth of the robot's main control system. The actual measured bus saturation threshold is 50 fps, which ensures the smoothness of the light strip animation while avoiding excessive bus resource consumption.

[0108] Frame discarding rules, namely: High-frequency message processing: When the message source publishes messages at a frequency higher than 30fps, such as when the motion control module publishes messages at a frequency of 60fps due to real-time attitude detection, time-interval triggered frame discarding is adopted. The specific rules are: record the timestamp of each frame message; if the time interval between the current frame and the previous retained frame is <33ms, 1 / 30fps≈33.3ms, then the current frame is discarded; if the time interval is ≥33ms, then the current frame is retained, and the "timestamp of the previous retained frame" is updated; Example: In a 60fps message stream, one frame is retained every 1 frame interval, that is, frames 1, 3, 5... are retained, and the final output frame rate is stable at 30fps.

[0109] Interpolation algorithm, namely: High-frequency message smoothing: For scenes that need to maintain animation continuity, such as dynamic alarm flashing effects, RGB component linear interpolation is used to generate transition frames. The specific steps are as follows: Let two adjacent valid frames be Frame1 and Frame2; Frame1: time t1, pixel colors are R1, G1, B1; Frame2: time t2, pixel colors are R2, G2, B2, and the time interval between the two frames is Δt = t2 - t1; If n transition frames need to be inserted within Δt, n = floor(Δt / 33ms)1, then the RGB component calculation formula for the k-th transition frame is, where 1 ≤ k ≤ n:

[0110] ,

[0111] ,

[0112] ;

[0113] The calculation results are rounded to the nearest integer to ensure that the color values ​​conform to the RGB range of 0-255.

[0114] Application example: Frame1: R=255, G=0, B=0, Frame2: R=255, G=255, B=0, Δt=66ms, then the transition frame color is: R=255+(255-255)×1 / 2=255, G=0+(255-0)×1 / 2=128, B=0, that is, RGB(255, 128, 0), realizing a smooth transition from red to yellow.

[0115] Frame buffering rules, namely: Low-frequency message processing: When the message source publishing frequency is lower than 30fps, such as the upper-layer application module's custom animation publishing frequency of 10fps, the last frame buffer reuse mechanism is adopted: The light strip arbitration module has a built-in frame buffer with a capacity of 1 frame, which stores the last received valid pixel data; each time a new frame is received, the buffer data is updated immediately; during the output cycle in which no new frame is received, the buffer data is repeatedly output; Example: In a 10fps message stream, each time a new frame of data is received, it is buffered and continuously output for 3 cycles, i.e., 3×33ms≈100ms, until the next new frame of data arrives, ensuring that the output frame rate is stable at 30fps.

[0116] The entire smoothing process is synchronously controlled by a high-precision timer. The timer triggers output events periodically with a fixed output frame rate. Within each output cycle, it comprehensively processes operations such as frame dropping, interpolation calculation, and buffer reading. This precise frame rate adjustment mechanism not only prevents high-frequency message sources from excessively occupying system bus resources, but also avoids display stuttering caused by low-frequency message sources. It optimizes the utilization of system resources while ensuring the visual smoothness of the light strip animation.

[0117] The timing mechanism of the LED strip arbitration module is a system-level status forced display window, which is implemented in the following ways:

[0118] Embed a high-priority timer in the arbitration logic, and assign a fixed display time window to a specific system-level state;

[0119] When the system monitoring module issues a system-level alarm status, the timer is triggered and the forced display window is activated.

[0120] During the forced display window, the LED strip arbitration module pauses the regular priority arbitration process and directly outputs the preset alarm LED strip effect;

[0121] After the forced display window ends, the LED strip arbitration module automatically resumes the normal arbitration process and selects the highest priority message for output.

[0122] It should be further explained that the timing mechanism of the LED strip arbitration module is to implement the system-level status forced display window by embedding a high-priority hardware timer in the arbitration logic. This timer runs independently of the main arbitration process and has the ability to interrupt the regular arbitration output. The system predefines a set of specific system-level states and their corresponding forced display time window parameters. These states include, but are not limited to, critical system states such as emergency stop, core hardware failure, and low battery alarm. Each state is associated with a preset LED strip display effect and a fixed display duration.

[0123] When the system monitoring module publishes a system-level alarm status through the DDS topic, the status monitoring unit of the arbitration module will immediately recognize the alarm message and trigger the forced display process. At this time, the timer starts counting and the forced display window is activated. During the forced display window, the main arbitration logic of the arbitration module is temporarily suspended, all messages from the regular status publication module will be ignored, and the system will directly output the preset alarm light strip effect. This effect is obtained by looking up the pre-stored pixel pattern library to ensure the consistency and timeliness of the display.

[0124] The duration of the forced display window is determined by preset parameters. During the window, a timer continuously monitors the remaining time. When the predetermined time is reached, the timer sends a termination signal, and the arbitration module immediately releases the forced display state and resumes the normal arbitration process. It automatically re-evaluates the priority of all currently active messages and selects the highest priority message for output. This forced display mechanism based on a hardware timer provides hardware-level display protection for critical system states, ensuring that even under high system load or software anomalies, the most important status information can still be reliably conveyed to the user through the LED strip.

[0125] The hardware abstract design of the LED strip arbitration module is implemented through a dynamic vector queue, including:

[0126] The vector queue serves as the carrier of the pixel color array in the data distribution service message, and its length is dynamically allocated at runtime based on the actual number of LED strip pixels.

[0127] The microcontroller is configured to parse a variable-length vector queue and drive the corresponding number of RGB LEDs;

[0128] When replacing the LED strip hardware with different pixel counts, only the pixel count parameter of the microcontroller needs to be adjusted, and all status publishing modules automatically adapt to the new length of the sending vector queue without modifying the software architecture.

[0129] It should be further explained that the hardware abstraction design of the LED strip arbitration module is implemented through a dynamic vector queue. This vector queue serves as the carrier of the pixel color array in the DDS message, and is encoded using a standardized serialization format. Each vector element contains complete RGB color information and its position index in the LED strip. During runtime, the system dynamically determines the length of the vector queue by querying the hardware configuration parameters of the connected LED strip. These configuration parameters are stored in non-volatile memory and are read by the microcontroller and broadcast to all status publishing modules during system initialization. The vector queue uses a contiguous storage space allocation method in memory, and the buffer size matching the number of LED strip pixels is dynamically allocated by the memory manager. When a message needs to be transmitted, the entire vector queue is converted into a byte stream through the DDS serialization interface for transmission, and the receiving end then deserializes it into the native data structure.

[0130] The microcontroller firmware is designed as a parsable variable-length vector queue. The number of RGB LEDs to be driven is determined by parsing the length field of the message header. Then, the color data in the vector queue is mapped to the corresponding physical LEDs in sequence. When the system needs to be upgraded or the LED strip hardware with a different number of pixels is replaced, only the pixel number parameter stored in the microcontroller needs to be updated through the configuration tool. All status publishing modules will automatically obtain the new pixel number through the query mechanism during the next status update and generate a vector queue of the corresponding length. The core software architecture of the system, including the arbitration algorithm and communication protocol, does not require any modification.

[0131] This hardware abstraction design based on dynamic vector queues decouples the software system from the hardware specifications at the protocol level, enabling the same software system to flexibly adapt to different specifications of LED strip hardware, thus improving the system's scalability and hardware compatibility.

[0132] The system supports secondary development by users through the publishing interface of the open data distribution service topic. User-defined applications only need to follow the unified message format and publish pixel data frames to the data distribution service topic to achieve custom light strip animation effects without modifying the light strip arbitration module and the underlying driver code.

[0133] It should be further explained that the system supports user-defined secondary development through a fully open data distribution service topic publishing interface. This interface provides user applications with a standardized software development kit, which includes message format definitions, application programming interface function libraries, and complete development documentation. User-defined applications only need to reference the provided function library and call the initialization function to establish a connection with the DDS domain. They can then send custom pixel data frames to the specified light strip control topic through a simple publishing function. These data frames must conform to a unified light strip control message format, including a compliant message header, a pixel color vector queue of the correct length, and valid priority fields and mode identifiers. At the implementation level, the system provides users with an auxiliary function library for pixel data generation, including common color transformation, light effect algorithms, and animation interpolation tools. Users can quickly build complex dynamic display effects by combining these basic functions without understanding the underlying communication details.

[0134] When users publish custom messages, these messages are transmitted to the LED strip arbitration module through the same DDS topic, and follow the same priority arbitration, frequency control and display process as messages published by the system's built-in functional modules, ensuring the consistency of the display logic between the user-defined state and the system state.

[0135] Throughout the secondary development process, users do not need to modify the core code of the LED strip arbitration module or the underlying hardware driver. They can create and deploy various personalized LED strip display effects simply by following the unified interface protocol and message specifications. This open architecture based on standardized interfaces greatly expands the system's flexibility and applicable scenarios, while maintaining the stability and reliability of the system core.

[0136] The LED strip arbitration module also includes a state persistence mechanism, which can load the last known valid state and priority mapping table from persistent storage after system restart or abnormal recovery, ensuring the continuity of display behavior.

[0137] It should be further explained that the state persistence mechanism of the LED strip arbitration module is achieved by establishing a non-volatile storage area and corresponding data management strategy. The system has specially allocated independent storage sectors in the non-volatile memory to save key system state data, including the currently active state mode, the latest version of the priority mapping table, and the last valid state information of each functional module.

[0138] When the system is running normally, the arbitration module writes the state changes to the persistent storage area in real time in a transactional manner. Each time a new state message is received and arbitration is completed, the system will save the currently effective state mode and its corresponding pixel data summary information to the specified storage address through a write operation. At the same time, a circular write strategy is adopted to avoid excessive erasing and writing to the same storage unit.

[0139] During data storage, the system adds version identifiers and timestamps to the stored content and uses a cyclic redundancy check algorithm to generate check codes to ensure the integrity and recoverability of the stored data. When the system detects a restart signal or recovers from an abnormal state, the bootloader will first call the state recovery routine. This routine first reads the last record in the persistent storage area, verifies the data integrity through the check code, then restores the configuration information of the priority mapping table and rebuilds the arbitration context environment in sequence, and finally initializes the light strip display effect according to the saved state mode information.

[0140] Throughout the recovery process, the system employs a phased verification mechanism, first restoring basic configuration data and then rebuilding the runtime state to ensure that display behavior remains continuous after system restart. This state persistence mechanism, through a carefully designed data storage structure and recovery process, effectively prevents the loss of display state due to system restart or anomalies, thereby improving the reliability of the entire LED strip display system and the consistency of user experience.

[0141] It should be further noted that, to ensure that those skilled in the art can reproduce the above-described state persistence mechanism, the following provides a detailed explanation of the storage medium selection, transaction atomicity implementation, data storage format, and loading / updating process:

[0142] The specific implementation of the state persistence mechanism includes the following:

[0143] Storage Media Selection and Configuration: In this embodiment, the persistent state storage medium uses an SPI interface Flash chip, model W25Q64JV, with the following specific parameters: Storage capacity: 64MBit, 8MB bytes, divided into two independent storage areas: Temporary storage area, address range: 0x000000-0x00FFFF, capacity 1MB: used for temporarily writing state data to be verified; Formal storage area, address range: 0x010000-0x07FFFF, capacity 7MB: used for storing final valid state data and priority mapping table; Read / write speed: SPI clock frequency 100MHz, single read / write speed ≥10MB / s, meeting real-time storage requirements; Erase method: supports page erase, 4KB / page, sector erase, 4MB / s, with the default data after erasure being 0xFF.

[0144] Transaction atomicity is achieved through a two-phase commit mechanism, which includes the following: To avoid write interruptions, such as data corruption caused by a sudden power outage, a two-phase commit mechanism of "writing to the temporary area first, then verifying and overwriting the permanent area" is adopted. The specific steps are as follows:

[0145] Phase 1: Temporary writing and verification, including the following: The LED strip arbitration module writes the status data to be stored, including the last valid status and priority mapping table, into the temporary storage area according to a preset format; after writing, the data in the temporary storage area is immediately read and compared with the original data at the byte level. The verification algorithm is CRC32, polynomial 0xEDB88320; if the verification passes, the second phase begins; if the verification fails, Phase 1 is re-executed, with a maximum of 3 retries. If it still fails, an error log is recorded.

[0146] The second stage: formal overwrite and marking, including the following: erasing the corresponding data pages in the formal storage area, such as erasing the 4KB page where the "last valid state" is located; writing the verification data from the temporary storage area to the corresponding address in the formal storage area; after writing, writing a "validation mark" (byte 0x55AA) at the end of the formal storage area to indicate that the current data in the formal area is valid.

[0147] During interrupt recovery, when the system restarts or recovers from an anomaly, the "valid flag" at the end of the formal storage area is read first: if the flag is 0x55AA, the formal area data is loaded directly; if the flag is not 0x55AA, it indicates that the last write interruption occurred, the temporary storage area data is read and verified, if the verification passes, the formal area is overwritten and a valid flag is added, if the verification fails, the default initial data, such as the default priority mapping table and standby state, is loaded.

[0148] The data storage format definition includes the following: the last valid state data format, stored in the official area address 0x010000-0x0100FF, as shown in the table below:

[0149] Field Name Field type Length (bytes) Meaning and Examples Data header Unsigned short integer 2 The fixed identifier 0xAA55 is used to identify the start of data. State pattern identifier String 32 The pattern identifier of the last valid state, such as "ALARM_OVERLOAD". Priority score Unsigned characters 1 The priority score of the last valid state, such as 10. Pixel data length Unsigned integer 4 The total number of bytes of RGB values ​​in the vector queue (e.g., 100 pixels × 3 bytes = 300). Pixel data byte array Variable (≤3072) The RGB data of the LED strip pixels (e.g., 300 bytes for 100 pixels). CRC32 checksum Unsigned integer 4 CRC32 checksum of all the above fields Data tail Unsigned short integer 2 The fixed identifier 0x55AA is used to identify the end of data.

[0150] The priority mapping table is stored in the formal area at addresses 0x020000-0x07FFFF. It uses a "header + entry" structure and supports dynamic addition / deletion of status entries, as detailed below: Header addresses 0x020000-0x020007:

[0151] Field Name Field type Length (bytes) meaning Header Label Unsigned short integer 2 Fixed 0xBB66 Total number of entries Unsigned integer 4 The number of entries in the priority mapping table, such as 20. Header CRC check value Unsigned short integer 2 CRC16 checksum of header field

[0152] An entry, that is, each entry is 38 bytes, and the address starts from 0x020008 and is stored consecutively, as shown in the table below:

[0153] Field Name Field type Length (bytes) Meaning and Examples Pattern identifier String 32 State pattern identifier, such as "STATE_STANDBY" Preset priority score Unsigned characters 1 The preset priority of this mode, such as 2 CRC check value of the entry Unsigned integer 4 CRC32 checksum of this entry Reserved bits Unsigned characters 1 Reserved, default 0xFF

[0154] The persistent data loading and updating process includes the following:

[0155] Data loading, i.e., when the system starts: read the header of the formal storage area table, verify the "valid flag" and CRC value; load the "last valid status data", parse the vector queue and priority score, and initialize the light strip display; load the "priority mapping table", parse all entries, and build the priority mapping table in memory, i.e., the hash table structure.

[0156] Data updates, i.e., during system runtime: When the priority mapping table is modified, such as when a user adds a new state through the configuration interface or when the last valid state changes, a persistent update is triggered; new data is written to Flash according to the "two-phase commit mechanism"; update frequency: the priority mapping table is updated immediately when it is modified, and the last valid state is updated every 500ms to avoid frequent Flash erasure and writing and extend its service life.

[0157] The system configures the reliability and real-time performance of message transmission through the service quality policy of the data distribution service, setting different service quality levels for different status messages to ensure low-latency transmission of high-priority status messages. It should be further noted that the system achieves fine-grained management of message transmission through the service quality policy configuration mechanism of the data distribution service. This mechanism allows for defining independent service quality level configurations for different types of light strip control messages, specifically through configuring a set of customizable service quality policy parameters. These parameters include, but are not limited to, reliability mode settings, transmission persistence configuration, resource limitation policies, and deadline constraints.

[0158] During implementation, the system classifies status messages into different quality of service levels based on their importance and real-time requirements. For example, the highest quality of service policy is configured for critical status messages such as low battery alarms, setting them to reliable transmission mode and assigning the shortest deadline constraint. Dedicated memory resources and network bandwidth are also allocated to them. Meanwhile, regular animation status messages are configured to maximum effort transmission mode and appropriate resource limits are set to prevent system overload.

[0159] The specific configuration of the service quality policy is managed through a structured configuration table, which records the mapping relationship between different mode identifiers and corresponding service quality levels. This configuration table is loaded during system initialization and these policy settings are applied through the application programming interface of the data distribution service.

[0160] During operation, when the status publishing module publishes a message, the data distribution service middleware will automatically match the corresponding quality of service policy according to the pattern identifier in the message, and control the message transmission behavior according to the parameters specified by the policy, including prioritizing the scheduling of high-priority messages when the network is congested, enabling fast transmission paths for messages with high real-time requirements, and performing traffic shaping control on low-priority messages.

[0161] This differentiated transmission management mechanism based on quality of service strategy ensures both low-latency and reliable transmission of high-priority status messages and the rational allocation and effective utilization of system communication resources through intelligent scheduling of communication resources.

[0162] An adaptive display method for robot status LED strips based on data distribution services and data streams, applied to a DDS-based data stream-driven adaptive display system for robot status LED strips, includes the following steps:

[0163] S1: The LED strip control data corresponding to the robot state is generated independently through multiple functional modules. The LED strip control data includes a pixel color array, a priority field, and a pattern identifier.

[0164] S2: Publish the LED strip control data as a continuous message stream to a unified topic through the data distribution service domain;

[0165] S3: Subscribe to a unified topic through the LED strip arbitration module, receive all message streams, and select the pixel data corresponding to the message with the highest priority as a candidate output frame in real time based on the priority mapping table;

[0166] S4: Set a fixed output frame rate through the LED strip arbitration module, reduce the frequency of high-frequency messages, and buffer the frames of low-frequency messages to ensure smooth output;

[0167] S5: Through the timing mechanism of the LED strip arbitration module, the preset LED strip effect is forcibly output when the system-level state is triggered;

[0168] S6: The microcontroller parses the final output instructions and drives the RGB light strip to display the corresponding effects.

[0169] It should be further explained that the execution process of this adaptive display method begins with each functional module independently generating LED strip control data based on the robot's real-time operating status. The system monitoring module is responsible for collecting power status and system health indicators, the motion control module detects the robot's motion mode and posture status, and the upper-layer application module generates corresponding status identifiers according to business logic requirements. Each module converts the status information into a standard message format containing a pixel color array, a priority field, and a pattern identifier by calling a unified data encapsulation interface. The pixel color array adopts a dynamic vector queue structure and automatically adjusts its length according to the number of currently connected LED strip pixels.

[0170] The generated messages are published to a unified LED strip control topic through the data distribution service domain. A differentiated transmission mechanism based on quality of service policy is used to ensure the reliable delivery of high-priority messages. The LED strip arbitration module, as the sole subscriber to this topic, processes the input message stream through a dual screening mechanism. The first screening compares the real-time priorities of all received messages based on a dynamically updated priority mapping table and ensures that the most important status is always selected for display by maintaining the index pointer of the current highest priority message. The second screening reduces the frequency of high-frequency messages and buffers low-frequency messages through a fixed output frame rate control mechanism. At the same time, a forced display window triggered by a hardware timer provides an uninterrupted display guarantee for system-level alarm status.

[0171] The final pixel data, determined through double screening, is parsed and transformed by the microcontroller's hardware abstraction layer. This abstraction layer can adaptively process vector queues of different lengths and map them to the corresponding pixels of the physical light strip, driving the RGB light strip to display a visualization effect that matches the current robot state. The execution of the entire method forms a complete control closed loop, realizing the adaptive mapping between the robot state and the light strip display through data flow driving. This ensures reliable display of important states while also optimizing the utilization of system resources and ensuring smooth and stable visual effects.

[0172] It should be further explained that the system consists of four main parts: a status publishing module, communication middleware, a light strip arbitration module, and light strip hardware. The status publishing module contains multiple functional modules, which correspond to the system monitoring module, motion control module, and upper-level application module in the robot's main control system. Each functional module independently generates light strip control data based on the robot's real-time operating status. This data includes a pixel color array, a priority field, and a mode identifier. The pixel color array uses a dynamically lengthed vector queue data structure, whose length is automatically determined during runtime based on the number of pixels in the actually connected light strip hardware. This design allows the system to adapt to light strip hardware of different specifications.

[0173] The functional modules within the status publishing module communicate through the data distribution service domain. Each functional module acts as a publisher of the data distribution service, publishing a continuous stream of light strip control messages to a unified data distribution service topic. Message transmission employs a standardized serialization format to ensure reliable data transmission between different modules.

[0174] The LED strip arbitration module, as the sole subscriber to the data distribution service topic, is responsible for receiving and processing all LED strip control messages. Internally, this module maintains a priority mapping table, which presets priority values ​​for each known robot state mode. When multiple messages are received, the arbitration module first parses the priority field and mode identifier in the message, then queries the priority mapping table to obtain the corresponding priority value. By comparing the priorities of all active messages in real time, it selects the pixel data corresponding to the message with the highest priority as the candidate output frame.

[0175] To ensure efficient use of system resources and smooth display, the LED strip arbitration module is set to a fixed output frame rate. For message sources with a frequency higher than the set output frame rate, the module employs a selective frame discarding algorithm to retain key animation frames at equal intervals while maintaining a stable output frame rate. For message sources with a frequency lower than the set output frame rate, the module uses a frame buffering mechanism to ensure continuous output of the last valid frame. This frequency control mechanism effectively prevents excessive consumption of system bus bandwidth while ensuring the continuity of visual effects.

[0176] The system also incorporates a forced display window mechanism to handle critical system states. When the system monitoring module issues a system-level alarm, a hardware timer in the LED strip arbitration module triggers the forced display process. During the forced display window, the regular arbitration process is paused, and the system directly outputs the preset alarm LED strip effect. This mechanism provides hardware-level display assurance for critical system states, ensuring that important status information is reliably displayed under any circumstances.

[0177] At the hardware abstraction level, the system employs a dynamic vector queue to decouple software from hardware. The vector queue serves as the carrier of pixel color arrays in the data distribution service message, and its length is dynamically determined based on the actual number of pixels in the LED strip. The microcontroller firmware is designed as a parsable, variable-length vector queue, determining the number of RGB LEDs to be driven by parsing the length field in the message header. When replacing the LED strip hardware with a different pixel count, only the pixel count parameter in the microcontroller needs to be updated, and all software modules automatically adapt to the new hardware specifications.

[0178] The system supports secondary development by users. Through the open data distribution service topic publishing interface, user-defined applications can publish custom LED strip control messages following a unified message format. The system provides a standardized software development kit, including message format definitions, application programming interface function libraries, and complete development documentation. Users can achieve various personalized display effects without modifying the LED strip arbitration module and underlying driver code.

[0179] To enhance system reliability, the LED strip arbitration module also incorporates a state persistence mechanism. This mechanism allocates independent storage areas in non-volatile memory to store the currently active state mode, priority mapping table, and the last valid state information of each functional module. When the system restarts or recovers from an anomaly, the system state is restored by reading the records in the persistent storage area, ensuring the continuity of display behavior.

[0180] At the communication layer, the system achieves fine-grained management of message transmission through the Quality of Service (QoS) strategy of the data distribution service. Different QoS levels are configured for messages based on their importance and real-time requirements. High-priority messages are transmitted reliably with shorter deadlines, while regular messages are transmitted best-effort with appropriate resource limits. This differentiated transmission management mechanism ensures both reliable transmission of critical messages and rational allocation of system communication resources.

[0181] The overall system workflow is as follows: Each functional module generates LED strip control data based on the robot's real-time status and publishes it to a unified topic through the data distribution service domain. The LED strip arbitration module receives and processes these messages, determining the final output frame through a dual screening mechanism. The first screening selects the most important status based on a priority mapping table, while the second screening ensures display quality and reliability through frequency control and forced display windows. The final determined pixel data drives the RGB LED strip to display the corresponding effect via a microcontroller.

[0182] This method achieves adaptive mapping between robot states and LED strip displays through a data stream-driven approach. While ensuring reliable display of critical states, it also optimizes system resource utilization and maintains smooth and stable visual effects. The synergistic effect of various technical features enables the system to intelligently coordinate the display needs of multiple functional modules, effectively avoiding state conflicts while providing flexible scalability.

[0183] A systemic innovation in robot status LED strip display was achieved through a distributed architecture based on data distribution services and an intelligent arbitration mechanism. This system effectively resolves the problem of multi-module display conflicts, ensuring that important states are presented first through dynamic priority arbitration, and optimizing system resource utilization while maintaining animation smoothness through an adaptive frequency control mechanism. Its data-driven model completely decouples state generation from display output, and, combined with hardware abstraction design, achieves seamless compatibility with LED strips of different specifications.

[0184] It provides a reliable system-level state protection mechanism, ensuring the immediate visibility of critical alarm states through a forced display window. Open secondary development interfaces allow users to flexibly customize display effects, while state persistence enhances the system's fault tolerance and recovery capabilities. These features together constitute a robot state display solution that meets real-time requirements and possesses good scalability, improving the intuitiveness and reliability of human-machine interaction.

[0185] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

Claims

1. A data stream-driven adaptive display system for robot status LED strips based on DDS, characterized in that, include: Status publishing module, communication middleware, LED strip arbitration module, and LED strip hardware; The status publishing module includes multiple functional modules, namely the system monitoring module, motion control module, and upper-layer application module in the robot main control system. Each functional module independently generates LED strip control data corresponding to the robot's status based on its own business logic. The LED strip control data includes a pixel color array, a priority field, and a mode identifier. As a publisher of the data distribution service, the functional module publishes a continuous stream of LED strip control messages to a unified data distribution service topic through the communication middleware. The pixel color array adopts a dynamically lengthed vector queue data structure, and the length of the vector queue is dynamically determined at runtime based on the number of pixels in the LED strip hardware. The communication middleware is a data distribution service domain, responsible for transmitting the light strip control messages between the status publishing module and the light strip arbitration module, ensuring reliable message distribution. The light strip arbitration module, as the sole subscriber to the data distribution service topic, continuously receives light strip control message streams from all the functional modules. The light strip arbitration module internally maintains a priority mapping table, which presets priority values ​​for each known robot state mode. The light strip arbitration module compares the priorities of all messages in real time based on the priority field in the received messages and the priority mapping table, and selects the pixel data corresponding to the message with the highest priority as a candidate output frame. The LED strip arbitration module also sets a fixed output frame rate, reduces the frequency of high-frequency messages, and buffers frames of low-frequency messages to maintain continuous output, ensuring smooth LED strip animation display. The LED strip arbitration module also includes a timing mechanism that reserves a fixed time window for specific system-level states. If a system-level alarm state exists within the time window, the preset LED strip effect is forcibly output. The light strip hardware includes a microcontroller and an RGB light strip. The microcontroller receives the final output instruction from the light strip arbitration module and drives the RGB light strip to display dynamic or static effects defined by the corresponding pixel color array.

2. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The process by which each functional module in the status release module independently generates LED strip control data includes: calculating the color value sequence of the corresponding LED strip pixels based on the real-time status changes of the robot, and encapsulating the color value sequence into a vector queue; the length of the vector queue is consistent with the number of hardware pixels of the target LED strip, the priority field is dynamically assigned according to the importance of the status, and the pattern identifier is used to identify the status type during the arbitration process.

3. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The priority arbitration process of the LED strip arbitration module includes: Continuously monitor the message stream incoming from the data distribution service topic; Parse the priority field and pattern identifier of each message; Query the priority mapping table in the internal storage to obtain the priority value of the corresponding state mode; Compare the priority values ​​of all active messages and select the pixel data corresponding to the message with the highest priority value as the current candidate output frame; The priority mapping table supports dynamic updates, allowing the addition, modification, or deletion of status modes and their priority settings through the configuration interface.

4. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The frequency control and flow smoothing mechanism of the LED strip arbitration module includes: Set a fixed output frame rate that is lower than the saturation threshold of the robot's main control system bus bandwidth; For message sources whose release frequency is higher than the fixed output frame rate, a frame dropping or interpolation algorithm is used to reduce the frequency so that the output frame rate matches the set value. For message sources whose publishing frequency is lower than the fixed output frame rate, the pixel data is cached after a new message is received, and the cached last frame of valid data is repeatedly output in subsequent output cycles until a new message arrives.

5. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The timing mechanism of the LED strip arbitration module is a system-level status forced display window, which is implemented in the following ways: A high-priority timer is embedded in the arbitration logic, and the timer is assigned a fixed display time window for a specific system-level state. When the system monitoring module issues a system-level alarm status, the timer is triggered and the forced display window is activated; During the forced display window, the LED strip arbitration module pauses the regular priority arbitration process and directly outputs the preset alarm LED strip effect; After the forced display window ends, the LED strip arbitration module automatically resumes the normal arbitration process and selects the message with the highest priority for output.

6. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The hardware abstract design of the LED strip arbitration module is implemented through a dynamic vector queue, including: The vector queue serves as the carrier of the pixel color array in the data distribution service message, and its length is dynamically allocated at runtime based on the actual number of LED strip pixels. The microcontroller is configured to parse a variable-length vector queue and drive a corresponding number of RGB LEDs; When replacing the LED strip hardware with different pixel counts, only the pixel count parameter of the microcontroller needs to be adjusted, and all status publishing modules automatically adapt to the new length of the sending vector queue without modifying the software architecture.

7. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The system supports secondary development by users through the publishing interface of the open data distribution service topic. User-defined applications only need to follow the unified message format and publish pixel data frames to the data distribution service topic to achieve custom light strip animation effects without modifying the light strip arbitration module and the underlying driver code.

8. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The LED strip arbitration module also includes a state persistence mechanism, which can load the last known valid state and priority mapping table from persistent storage after system restart or abnormal recovery, ensuring the continuity of display behavior.

9. The DDS-based data stream-driven adaptive display system for robot status LED strips according to claim 1, characterized in that: The system configures the reliability and real-time performance of message transmission through the quality of service (QoS) policy of the data distribution service, and sets different QoS levels for different status messages to ensure low-latency transmission of high-priority status messages.

10. A method for adaptive display of robot status light strips based on data distribution services and data stream driving, characterized in that, Applied to the system as described in any one of claims 1 to 9, comprising the following steps: S1: The light strip control data corresponding to the robot state is generated independently by multiple functional modules. The light strip control data includes a pixel color array, a priority field, and a mode identifier. S2: Publish the light strip control data as a continuous message stream to a unified topic through the data distribution service domain; S3: Subscribe to the unified topic through the LED strip arbitration module, receive all message streams, and select the pixel data corresponding to the message with the highest priority as the candidate output frame in real time based on the priority mapping table; S4: Set a fixed output frame rate through the LED strip arbitration module, reduce the frequency of high-frequency messages, and buffer the frames of low-frequency messages to ensure smooth output; S5: Through the timing mechanism of the LED strip arbitration module, a preset LED strip effect is forcibly output when the system-level state is triggered; S6: The microcontroller parses the final output instructions and drives the RGB light strip to display the corresponding effects.

Images