Equipment capability self-description and negotiation method and device, upper computer and storage medium

Abstract

The invention belongs to the technical field of robot communication interaction, and relates to an equipment capability self-description and negotiation method and device, an upper computer and a storage medium. The peripheral equipment is powered on to issue an equipment access instruction, so that the upper computer obtains the types and the number of the peripherals in the system in real time; state and capability information is obtained based on a unified standard frame, operation parameters and controllable range structuring are achieved, and a basis is provided for unified control; a control instruction template is automatically generated according to the information, multiple sets of adaptive logics are not needed, cross-device instruction and strategy multiplexing is supported, and the extension and operation and maintenance cost is reduced; the target execution instruction is issued through the preset verification strategy, problems can be found in advance when parameters cross boundaries or condition conflicts occur, wrong execution is avoided, the system stability is improved, peripheral automatic identification, capability unified expression, instruction template automatic generation and safe execution are achieved, and the compatibility and reliability of a robot system in a multi-device environment are enhanced.

Description

Technical Field

[0001] This application belongs to the field of robot communication and interaction technology, specifically relating to a device capability self-description and negotiation method, apparatus, host computer, and storage medium. Background Technology

[0002] With the deployment of service robots, mobile robots, and automated equipment in various environments, robots typically need to connect to multiple types of peripheral devices, such as lighting, door locks, elevators, sensors, and battery management modules. However, peripherals from different vendors and versions differ significantly in communication protocols, command definitions, and status representations, requiring the host computer to maintain multiple sets of adaptation logic, resulting in high system expansion and maintenance costs. Existing systems generally rely on static configuration to issue peripheral commands and read status, but this method cannot adapt to changes in device versions or the addition of new devices, easily leading to control flow failures.

[0003] In the process of realizing this application, the inventors discovered that the prior art has at least the following problems: First, after the system is powered on, the host computer has difficulty in obtaining the actual types and quantities of connected peripherals in a timely manner, making it difficult to perform unified scheduling; Second, different peripherals lack structured expression methods for status and capability information, making it difficult for the host computer to extract device operating parameters and controllable ranges in a timely manner; Third, there is a lack of instruction generation mechanism based on device capabilities, requiring the host computer to maintain control templates separately for each type of peripheral, making it difficult to achieve cross-device reuse; Fourth, the instruction issuance lacks unified verification, which can easily lead to execution failure due to parameter out-of-bounds or control limit conflicts, affecting system stability. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a device, host computer, and storage medium for device capability self-description and negotiation. This enables unified access to peripheral devices and acquisition of self-description information after power-on, and automatic generation of control command templates based on this information. This achieves centralized management and unified control of peripheral devices, improving the system's scalability, compatibility, and stability.

[0005] To address the aforementioned technical problems, one technical solution adopted in this application is as follows: a device capability self-description and negotiation method is provided, applied to a host computer. The host computer and each peripheral device communicate via a preset standard frame. The method includes: when each peripheral device is powered on, a device access command is sent to each peripheral device, so that each peripheral device returns a target device list information to the host computer according to the device access command; based on the target device list information, a device information retrieval command is sent to each peripheral device, so that each peripheral device returns its corresponding status information and capability information to the host computer according to the device information retrieval command; a control command template is generated based on the status information and capability information corresponding to each peripheral device; based on the control command template and a preset verification strategy, a target execution command is selected and sent to each peripheral device, so that each peripheral device returns an execution feedback result to the host computer according to the target execution command; wherein, the device access command, the device information retrieval command, and the target execution command are sent via a standard frame.

[0006] In some embodiments, the format of a standard frame includes a frame version number, a message type number, a three-level addressing field, a frame sequence number, a length, a data area, and a frame checksum.

[0007] In some embodiments, the three-level addressing field includes the peripheral device type classification number, the peripheral device number, and the peripheral device instance number.

[0008] In some embodiments, selecting a target execution instruction based on a control instruction template and a preset verification strategy includes: obtaining a device execution instruction based on the control instruction template; verifying the device execution instruction; when the device execution instruction meets the constraint verification conditions, determining whether the device execution instruction meets the conflict verification conditions; if the device execution instruction meets the conflict verification conditions, using the device execution instruction as the target execution instruction; if the device execution instruction does not meet the conflict verification conditions, executing a conflict resolution process.

[0009] In some embodiments, the method further includes: when the host computer detects an abnormal situation during communication with various peripheral devices or execution of instructions, executing a non-blocking compatibility degradation process.

[0010] In some embodiments, the method further includes: receiving health monitoring data reported by each peripheral device; analyzing the health monitoring data; and if the health monitoring data is in an abnormal state range, standardizing the health monitoring data through a preset event semantic standardization processing strategy to obtain target health data.

[0011] In some embodiments, the method further includes: when the host computer sends a target execution instruction to each peripheral device through a standard frame, performing an idempotency and deduplication control process based on the frame sequence number carried in the standard frame.

[0012] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a device capability self-description and negotiation apparatus, comprising: a target device list information acquisition module, used to send device access instructions to each peripheral device when each peripheral device is powered on, so that each peripheral device returns target device list information to the host computer according to the device access instructions; a device detail information acquisition module, used to send device information acquisition instructions to each peripheral device according to the target device list information, so that each peripheral device returns corresponding status information and capability information to the host computer according to the device information acquisition instructions; a control instruction template generation module, used to generate control instruction templates according to the status information and capability information corresponding to each peripheral device; and a target execution instruction selection and execution module, used to select target execution instructions according to the control instruction templates and a preset verification strategy, and send target execution instructions to each peripheral device, so that each peripheral device returns execution feedback results to the host computer according to the target execution instructions; wherein, the device access instructions, device information acquisition instructions, and target execution instructions are sent through standard frames.

[0013] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a host computer, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned method.

[0014] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium that stores computer-executable instructions, which, when executed by a host computer, cause the host computer to execute the above-mentioned method.

[0015] Unlike related technologies, this application provides a method, apparatus, host computer, and storage medium for device capability self-description and negotiation. By actively issuing device access commands when peripheral devices are powered on, the host computer can obtain the type and quantity of peripheral devices actually existing in the system in real time. Based on a unified standard frame, it acquires the status and capability information of each peripheral device, realizing a structured expression of device operating parameters and controllable ranges, providing a basis for subsequent unified control. It automatically generates control command templates based on the status and capability information of each peripheral device, eliminating the need for the host computer to maintain multiple sets of adaptation logic for different peripheral devices. This enables cross-device reuse of command formats and control strategies, significantly reducing system expansion and maintenance costs. Based on a preset verification strategy, it selects and issues target execution commands, which can detect problems in advance when parameters exceed limits, conditions conflict, or execution restrictions are not met, avoiding execution failures due to erroneous commands and improving the overall stability of the system. Based on this, this application can achieve automatic identification of peripheral devices, unified capability description, automatic generation of command templates, and safe execution of controlled commands, improving the scalability, compatibility, and stability of robot systems in multi-device and multi-model environments. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0017] Figure 1 This is a schematic diagram illustrating a specific application scenario of a device capability self-description and negotiation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the hardware structure of a host computer provided in an embodiment of this application; Figure 3 This is a flowchart of a device capability self-description and negotiation method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a device capability self-description and negotiation apparatus provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0019] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0020] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0021] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating a specific application scenario of a device capability self-description and negotiation method provided in an embodiment of this application. For example... Figure 1 As shown, this application scenario includes a host computer 10 and multiple peripheral devices 20 (e.g., peripheral device 21, peripheral device 22, ..., peripheral device N). The host computer 10 and each peripheral device 20 communicate with each other through a unified standard frame.

[0022] The host computer 10 is typically used for centralized management, scheduling, and control of peripheral devices 20. It is responsible for issuing control commands, receiving status and capability information, generating control command templates, executing verification strategies, and processing feedback results. The host computer 10 can be a server, industrial computer (IPC), personal computer (PC), or cloud platform, etc. In this embodiment, the host computer 10 is a server, and its main functions include: command sending, capability information collection and modeling, control template generation, execution verification and feedback processing, data storage and analysis, and human-machine interface.

[0023] Peripheral devices 20 are typically execution or sensing modules connected to the robot system, such as lighting equipment, door locks, elevator control modules, sensors, or battery management units (BMS). Each peripheral device 20 executes operations according to standard frame instructions issued by the host computer 10, and simultaneously feeds back its own status and capability information to the host computer 10 for dynamic modeling, template generation, and safety control, thereby achieving unified management and collaborative control in multi-device and multi-model environments.

[0024] The standard frame format includes a frame version number, message type number, three-level addressing field, frame sequence number, length, data area, and frame checksum.

[0025] The three-level addressing domain includes the peripheral device type classification number, the peripheral device number, and the peripheral device instance number.

[0026] To achieve unified communication between the host computer 10 and multiple peripheral devices 20, the host computer 10 and the peripheral devices 20 exchange information through standard frames. Standard frames define the basic communication format, supporting peripheral devices of different models and vendors, enabling unified management and control across devices. Specifically, a standard frame consists of the following parts: (1) Frame version number ([VER]): Used to identify the version information of the standard frame to ensure compatibility between different firmware versions or host computer software. For example, when the frame format is upgraded or new fields are added, the version number can be used to determine whether the frame needs to be parsed or the new fields should be ignored, thus achieving forward compatibility.

[0027] (2) Message Type Number ([MID]): Used to identify the data type or function category carried by the frame, including discovery / description class (0x10~0x12), command / response class (0x20~0x21), event class (0x30), and configuration class (0x40~0x41). The message type number guides the host computer to parse the data content and determine the subsequent processing flow. For example, if the host computer receives MID=0x10, it means that the frame is a discovery command response and the device list information needs to be extracted; MID=0x21 means that the command is ACK and the execution status needs to be updated.

[0028] (3) Three-level addressing domain ([Class][Node][Inst]): Used to uniquely identify peripheral devices and their instances, realizing unified device abstraction and addressing. Specifically, it includes: Device type classification number (Class): Identifies the functional type of the peripheral device, such as lighting equipment 0x01, door lock 0x02, elevator 0x03, BMS 0x04, sensor 0x05, etc., ensuring cross-model address semantic stability and facilitating unified scanning and scheduling. Peripheral device number (Node): Uniquely identifies different physical devices under the same device type. For example, in a multi-channel lighting control system, Node=0x01 may correspond to the first light strip, and Node=0x02 may correspond to the second light strip. Peripheral device instance number (Inst): Used to identify different instances or sub-modules within the same physical device. For example, different segments of multiple light strips, or different measurement channels of multiple-channel sensors, can be distinguished by Inst, realizing independent control of multiple instance devices.

[0029] (4) Frame Sequence Number ([SEQ]): A 1-byte field used to identify the transmission order of frames, implementing idempotent control and deduplication mechanisms. When the host computer sends a command, SEQ increments by 1 (0~255 cycle). The node uses SEQ to determine whether it is a duplicate command, avoiding repeated execution. For example, when the previous command is retransmitted due to ACK loss, the node can directly return the historical ACK through SEQ and execution fingerprint, without repeating the action.

[0030] (5) Length ([LEN]): Used to indicate the byte length of the data area, ensuring that TLV data can be accurately intercepted during frame parsing and preventing out-of-bounds parsing.

[0031] (6) Data Area ([TLV...]): Carries peripheral device status information (VENDOR, MODEL, P / N_LIST, VER_MAJOR / MINOR, FW_HASH, SUPPORT_CLASS_SET, CFG_NAMESPACE, etc.), capability information (CAP_ID, ACCESS (R / W / SUB), UNIT, RANGE_MIN / MAX, STEP / RESO, BOUND_POLICY (truncation / rejection / degradation), INSTANCE_MASK, DEFAULTS, etc.), as well as command parameters or event data. The TLV structure (Type-Length-Value) facilitates flexible expansion and unified parsing across devices.

[0032] (7) Frame check code ([CRC16]): Used to detect whether an error occurs in the frame during transmission to ensure communication reliability. Before parsing the frame, the host computer or peripheral device will check the CRC16 value. If the check fails, the frame will be discarded or a retransmission will be requested.

[0033] For example, suppose the robot's host computer needs to control a multi-segment LED strip peripheral device (Node=0x01). This LED strip has two segments (Inst=0x01, 0x02). The host computer wants to set the brightness of the first segment to 50% and the brightness of the second segment to 70%. The control command is sent to the LED strip peripheral device through a standard frame format, which is: [VER][MID][Class][Node][Inst][SEQ][LEN][TLV...][CRC16]. In this data structure, VER=0x01 indicates the current frame format version; MID=0x20 indicates a command-type frame; Class=0x01 indicates a lighting device; Node=0x01 indicates the first light strip; Inst=0x01 indicates the first light strip segment; SEQ=0x05 indicates the fifth command, supporting idempotent control; LEN=0x03 indicates this data area contains a 3-byte TLV; TLV... (Type=SET_BRIGHTNESS, Length=1, Value=50), the TLV structure indicates that the brightness is set to 50%; CRC16=0xABCD, used for transmission verification. If the data is simultaneously sent to the second light strip segment, Inst can be changed to 0x02, Value to 70, and the remaining fields can remain unchanged. SEQ can be incremented by 1 (0x06).

[0034] Understandably, the host computer uses [Class][Node][Inst] to accurately locate the target device and instance, ensuring that instructions are sent to the correct object; the [SEQ] field allows nodes to identify duplicate and out-of-order frames, enabling idempotency and deduplication control; the TLV data area provides a structured description of command types and parameters, can be extended to support various device capabilities, and facilitates the host computer to automatically generate control templates; [CRC16] ensures the reliability of frames in serial port, CAN, or wireless network transmission.

[0035] The standard frame format described in this embodiment achieves structured, scalable, and reliable communication between the host computer and various peripheral devices by clearly defining frame version number, message type number, three-level addressing field, frame sequence number, length, data area, and frame checksum. The frame version number ensures forward compatibility during protocol upgrades or version iterations; the message type number distinguishes between different functions such as discovery, description, command, event, and configuration, enabling the host computer to accurately parse and process various types of information; the three-level addressing field consists of device type classification number, number, and instance number, ensuring that instructions and data can be accurately located to specific peripheral devices and instances, facilitating unified scheduling across different models and multiple instances; the frame sequence number supports sequence control, duplicate detection, and idempotent processing, improving system reliability in complex communication environments such as retransmission and out-of-order delivery; the TLV structure of the length field and data area makes information transmission flexible and scalable, supporting unified expression of status information, capability parameters, and control commands; and the frame checksum ensures the integrity and correctness of data during transmission. Through the above design, the standard frame not only improves communication reliability and system stability, but also facilitates the automatic generation of control command templates by the host computer, enabling centralized management of peripheral devices, cross-device control, and efficient collaborative operation in multi-model environments, thereby significantly reducing system adaptation and maintenance costs.

[0036] Please see Figure 2 The diagram illustrates the hardware structure of the host computer 10. The host computer 10 includes: at least one processor 11; and a memory 12 communicatively connected to the at least one processor 11. Figure 2 Taking a processor 11 as an example, the memory 12 stores instructions executable by at least one processor 11. These instructions, when executed by the at least one processor 11, enable the at least one processor 11 to perform the device capability self-describing and negotiation method of this embodiment. The processor 11 and the memory 12 can be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.

[0037] The memory 12, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the device capability self-description and negotiation method in the embodiments of this application. The processor 11 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 12, thereby implementing the device capability self-description and negotiation method in the embodiments of this application.

[0038] The memory 12 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computing device. Furthermore, the memory 12 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 12 may optionally include memory remotely located relative to the processor 11, and these remote memories may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] One or more modules are stored in memory 12 and, when executed by one or more processors 11, execute the device capability self-description and negotiation method of this application embodiment.

[0040] The implementation process of a device capability self-description and negotiation method provided in this application will be described in detail below with reference to specific embodiments.

[0041] Please see Figure 3 , Figure 3 This is a flowchart illustrating a device capability self-description and negotiation method provided in an embodiment of this application. This device capability self-description and negotiation method is applied to the aforementioned host computer 10. For example... Figure 3 As shown, the method includes steps S11-S14: S11: When each peripheral device is powered on, a device access command is sent to each peripheral device so that each peripheral device returns the target device list information to the host computer according to the device access command.

[0042] When each peripheral device is powered on, the host computer first actively probes for available peripheral devices in the system by sending a device access command. This command is sent via a preset standard frame, which includes a frame version number (VER), message type number (MID), three-level addressing fields (Class / Node / Inst), frame sequence number (SEQ), length (LEN), data area (TLV...), and frame checksum (CRC16) to ensure the integrity and reliability of information transmission. The three-level addressing fields consist of a device type classification number (Class, e.g., 0x02 for door locks, 0x01 for lighting), a device number (Node, uniquely identifying a device), and an instance number (Inst, identifying multiple instances of the same type of device), used to uniquely identify each peripheral device and its instance in the system.

[0043] Upon receiving a device access command, each peripheral device responds and returns a list of target devices. This list includes the type, number, and instance number of the currently online peripheral devices. The returned information is also encapsulated in a standard frame to ensure that the host computer can accurately parse and identify all online peripheral devices. For example, in a service robot system, if there are two LED strips (Class=0x01, Node=0x01 / 0x02) and a door lock (Class=0x02, Node=0x01) after power-on, the device access command will trigger each peripheral device to return its corresponding list, allowing the host computer to obtain complete online device topology information.

[0044] By sending device access commands and obtaining target device list information, the host computer can instantly and accurately determine the actual online peripheral types, quantities, and instance distribution in the system after the peripheral devices are powered on. This process enables dynamic perception of device online status, allowing the host computer to uniformly schedule various peripheral devices based on real-time topology information. This avoids control blind spots and system compatibility issues caused by relying on static configurations, ensuring the reliability and scalability of subsequent control processes.

[0045] S12: Based on the target device list information, send device information retrieval instructions to each peripheral device, so that each peripheral device returns its corresponding status and capability information to the host computer according to the device information retrieval instructions.

[0046] Based on the target device list information obtained in step S11, the host computer sends a device information retrieval command for each peripheral device to obtain the status and capability information of the peripheral device. The status information includes vendor information (VENDOR), model (MODEL), parts list (P / N_LIST), firmware version (VER_MAJOR / MINOR), and supported device type set (SUPPORT_CLASS_SET), reflecting the static information and basic characteristics of the peripheral device. The capability information describes the controllable capabilities of the peripheral device, such as supported operating parameters (CAP_ID), access type (read / write / subscribe), parameter unit (UNIT), value range (RANGE_MIN / MAX), step size (STEP / RESO), boundary policy (BOUND_POLICY), instance mask (INSTANCE_MASK), and default values ​​(DEFAULTS), used to clarify the device's operating parameters and controllable range.

[0047] During the acquisition of status and capability information, peripheral devices can return information in packets, including frame sequence numbers (SEQ) to support packet reordering and idempotent processing. This ensures that even in the event of communication delays or packet loss, the host computer can accurately reassemble the device capability information. For example, for a four-segment LED strip, the capability information can be returned in four instance segments, each containing brightness range, mode list, and step size information. After parsing, the host computer can form a unified device capability model, providing complete data for generating control command templates in subsequent steps (step S13).

[0048] By acquiring the status and capability information of peripheral devices, the host computer can structurally grasp the operating parameters, controllable range, and operational constraints of each peripheral device, achieving unified expression and standardized management of device capabilities. This not only provides complete data for automatically generating control command templates but also enables the system to dynamically adapt to the capability differences of peripheral devices of different models and suppliers, improving the cross-device reusability of control strategies and the overall stability of system operation.

[0049] S13: Generate control command templates based on the status and capability information corresponding to each peripheral device.

[0050] The host computer automatically generates control command templates based on the status and capability information obtained from various peripheral devices. The specific process includes: (1) Mapping Capability Information to Command Slots: The host computer parses the capability information returned by each peripheral device and maps the controllable operations to predefined command slots. For example, for lighting devices, capability information may include brightness range (0~100%), mode options (BREATH, CHASE), step size (STEP), and unit (%); for door lock devices, capability information may include LOCK / UNLOCK operations and access permissions. Each command slot is automatically appended with an instance number and device type information to achieve unified management of multiple instances and multiple models.

[0051] (2) Template structuring: The generated control instruction template is structured, including operation type, controllable range, step size, unit, constraints and instance information. This template can be used by the host computer for subsequent instruction selection and scheduling, realizing "plug and play across devices" without the need for separate hard-coded instructions for each peripheral.

[0052] For example, for a lighting device with 4 light strips, the control instruction template may contain 4 command slots, each corresponding to the brightness adjustment and mode setting of one light strip segment; for light strips coupled to the red channel, the maximum current constraint of that channel needs to be marked in the template.

[0053] S14: Select the target execution instruction according to the control instruction template and the preset verification strategy, and send the target execution instruction to each peripheral device so that each peripheral device returns the execution feedback result to the host computer according to the target execution instruction; among them, the device access instruction, the device information acquisition instruction, and the target execution instruction are sent through standard frames.

[0054] The process of selecting a target execution instruction based on a control instruction template and a preset verification strategy includes: obtaining the device execution instruction based on the control instruction template; verifying the device execution instruction; determining whether the device execution instruction meets the conflict verification conditions when it meets the constraint verification conditions; using the device execution instruction as the target execution instruction if it meets the conflict verification conditions; and executing the conflict resolution process if the device execution instruction does not meet the conflict verification conditions.

[0055] The host computer generates the final executable command (i.e., an executable command for a specific peripheral device, operation, and parameters) based on the control command template and preset verification strategy generated in step S13. The specific process includes: (1) Obtaining Device Execution Instructions: The host computer selects the operation to be executed from the control instruction template and converts it into an execution instruction that the device can understand. Each device execution instruction includes: target device, operation type (such as brightness adjustment, on / off, mode setting), operation parameters (such as brightness value, mode enumeration), and instance number. For example, for a light strip, the device execution instruction may be "Adjust the brightness of light strip segment 1 to 80%", corresponding to the specific device type, number, and instance number.

[0056] (2) Perform constraint verification: Verify the device execution instructions to determine whether they meet the constraint verification conditions. Constraint verification conditions refer to the basic operational restrictions that the device execution instructions must meet to ensure that the instructions are executable within the device's capabilities. Verification content includes: parameter boundary verification: parameter values ​​are within the device's capabilities (e.g., brightness 0~100%); unit / step verification: parameter units and step distances conform to the device's capability definition; time constraints: periodic execution instructions must be within the allowed time range; resource and coupling checks: such as current limits for the LED strip's red channel and power / energy consumption limits. If the device execution instructions meet all constraint conditions, proceed to the next step; otherwise, the instructions are rejected or adjusted.

[0057] (3) Conflict verification: Determine whether the device execution command meets the conflict verification conditions; if the device execution command meets the conflict verification conditions, the device execution command is taken as the target execution command; if the device execution command does not meet the conflict verification conditions, the conflict resolution process is executed. It can be understood that the conflict verification conditions are used to determine whether there is a conflict between multiple device execution commands, such as mutual exclusion operations or resource contention. The verification content includes: mutual exclusion of operations: conflicting operations are not allowed to be executed simultaneously on the same device or channel (such as simultaneous execution of RED and GREEN duty cycle conflict); priority conflict: different task priorities (security > navigation > decoration), higher priority tasks are executed first; time or resource conflict: multiple instances or multiple devices conflict in time or power. If the device execution command meets the conflict verification conditions (i.e., no conflict or the conflict has been covered by the allowed policy), then the command is determined as the final target execution command.

[0058] (4) Execution of Conflict Resolution Process: When the device executes an instruction that does not meet the conflict verification conditions, the host computer executes the conflict resolution process to adjust the conflicting instruction to an executable state. Conflict resolution strategies include: parameter adjustment: such as reducing brightness, extending duty cycle, and replacing color; sequential scheduling: re-queuing execution according to priority and time window; degrading processing: partially replacing or delaying the execution of high-priority tasks to ensure safety. Finally, a set of target execution instructions that have undergone conflict resolution is generated to ensure that they can be safely issued and executed, while recording execution fingerprints to support idempotency and repeated execution processing. For example, if the red breathing mode of the navigation warning light conflicts with the red channel current limit, the conflict resolution process will automatically reduce the brightness of the red breathing or replace it with amber, while adjusting the synchronization time of multiple light strips to ensure the safe execution of the task.

[0059] (5) Command issuance and feedback: The final target execution command is sent to the corresponding peripheral device through a standard frame. After the peripheral device executes the command, it returns the execution feedback result. The host computer updates the status based on the feedback and can trigger subsequent strategies or event processing.

[0060] By combining control command templates with preset verification strategies, the security, reliability, and controllability of commands executed on peripheral devices are ensured. Specifically, before selecting a target execution command, the host computer first checks the command parameters across multiple dimensions, including boundaries, units, step size, time, and resource usage, based on constraint verification conditions. This ensures that the operation does not exceed the device's capabilities or violate execution constraints, thus avoiding execution failures due to parameter errors. Subsequently, conflict verification conditions are used to determine whether there are priority conflicts or mutually exclusive operations among multiple commands. When a conflict is detected, a conflict resolution process is executed. By adjusting the execution order, downgrading the algorithm, or replacing parameters, the final executable target execution command is generated. This ensures that even in cases of complex resource coupling or multi-strategy conflicts, the system can still complete the task safely and continuously. Ultimately, this process ensures that the target execution command is correctly executed after being sent to each peripheral device, and closed-loop confirmation is achieved through execution feedback. This significantly improves the command execution stability, task completion rate, and system robustness of the robot system in multi-device and multi-model environments.

[0061] In some embodiments, the method further includes: when the host computer detects an abnormal situation during communication with various peripheral devices or execution of instructions, executing a non-blocking compatibility degradation process.

[0062] When the host computer detects an anomaly during communication with peripheral devices or command execution, it will initiate a non-blocking compatibility degradation process to ensure that the main system flow is not interrupted by a single peripheral device malfunction. The specific process is as follows: First, when the host computer detects an anomaly, such as an external device returning unknown capability information, a command key value not existing, communication timeout, or the device being temporarily unreachable, the host computer will not immediately terminate the entire control process. Instead, it will determine the handling strategy based on the anomaly type. For negligible anomalies, the system will skip the instruction or revert to the default value and mark the device or instruction as "DEGRADED" in the internal event or health status log to indicate that the device is currently in a state of functional limitation. Simultaneously, the host computer will record detailed compatibility logs, including the anomaly type, affected devices, timestamp, and handling method, for subsequent maintenance analysis.

[0063] For commands involving multiple instances of devices, the host computer will individually process the results for each instance and generate overall summary information. For example, it may use a bitmap to identify whether each instance succeeded or failed, along with a reason code. This ensures that even if some instances cannot execute the command, the remaining instances can continue to operate. For instance, if the robot controls four LED strips simultaneously, and one of them becomes unexecutable due to a hardware version update, the host computer will perform a downgrade process on that segment (such as using the default brightness or ignoring the segment) and record the DEGRADED status. The other three LED strips can still operate normally according to the predetermined strategy.

[0064] In this embodiment, a non-blocking compatibility degradation process is initiated when an anomaly is detected during communication or instruction execution between the host computer and various peripheral devices. This allows the system to maintain the overall control flow even when faced with peripheral instances of unknown capabilities, missing key values, or temporary unreachability. This mechanism ensures that even if some peripheral functions are limited or abnormal, other devices can still operate normally. Simultaneously, by marking events / health status as DEGRADED and recording compatibility logs, it provides a reference for operation and maintenance. For multi-instance devices, execution results are reviewed and summarized for each instance, achieving a control effect where partial success is acceptable. This significantly improves the robustness, compatibility, and continuous operation capability of the robot system in environments with multiple models, versions, and heterogeneous peripherals.

[0065] In some embodiments, the method further includes: receiving health monitoring data reported by each peripheral device; analyzing the health monitoring data; and if the health monitoring data is in an abnormal state range, standardizing the health monitoring data through a preset event semantic standardization processing strategy to obtain target health data.

[0066] During operation, the host computer continuously receives health monitoring data reported by various peripheral devices. This data typically includes key operating parameters of the peripheral devices, such as battery temperature, current, voltage, sensor status, actuator load, etc., collectively referred to as health monitoring data.

[0067] Upon receiving the health monitoring data, the host computer analyzes it to determine whether each parameter is within the normal range. For example, it checks if the battery temperature exceeds a set threshold, if sensor outputs are abnormal, or if any control signals are missing. If the analysis shows that a health monitoring data point is outside the normal range or exhibits an abnormal state, the host computer will convert the health monitoring data into target health data in a unified format based on a preset event semantic standardization processing strategy.

[0068] The event semantic standardization processing strategy maps raw health codes reported by different models and suppliers to a unified event class (EVT_CLASS), event number (EVT_ID), and status flags (FLAGS). The high four bits of the status flags represent the status category (e.g., OK, WARN, ALARM, DEGRADED), while the low four bits record version information or sub-states. After this standardization, health monitoring data forms structured target health data. For example, battery overheating events from different peripheral devices can be uniformly represented as EVT_BATT_OVTEMP, which can include maximum, minimum, current, average, and status version information. The host computer can then use the target health data for further policy triggering, alarm processing, or historical record storage, ensuring that regardless of the model or manufacturer of the peripheral devices, the system can obtain health information in a unified and resolvable form. This improves the robot system's ability to monitor health status and enhance operational controllability in multi-model, multi-peripheral environments. For example, when two different manufacturers' BMS report their respective over-temperature codes, after standardization processing, the system uniformly identifies it as EVT_BATT_OVTEMP and triggers the corresponding power reduction or safe shutdown strategy to achieve a consistent response across different models.

[0069] In this embodiment, by receiving and analyzing health monitoring data reported by various peripheral devices, abnormal device states, such as excessively high temperature, abnormal voltage, or sensor failure, can be detected in a timely manner. Combined with a preset event semantic standardization processing strategy, the raw health information reported by different models or different suppliers is unified into structured and parsable target health data, enabling the system to trigger alarms, execute strategies, and manage historical records in a consistent manner. This improves the robot system's health monitoring capabilities, operational controllability, and operational safety in multi-device and multi-model environments.

[0070] In some embodiments, the method further includes: when the host computer sends a target execution instruction to each peripheral device through a standard frame, performing an idempotency and deduplication control process based on the frame sequence number carried in the standard frame.

[0071] First, when sending each target execution instruction, the host computer records a unique sequence number for the current instruction in the frame sequence number field of the standard frame. This sequence number increments cyclically to identify the transmission order of the instructions. Subsequently, after receiving the standard frame, each peripheral device determines whether the instruction is a duplicate based on the frame sequence number and historical execution records: if the instruction corresponding to the frame sequence number has already been successfully executed and returned an ACK, the peripheral device directly returns the historical ACK information without re-execution, achieving idempotency; if the instruction corresponding to the frame sequence number has not been executed, the instruction is executed normally and an ACK is returned. Simultaneously, the host computer maintains N execution fingerprint or ACK digest caches to identify duplicate or out-of-order instructions and correctly handles out-of-order instructions within a tolerance window, avoiding multiple executions or sequence errors caused by network latency or frame loss.

[0072] For example, suppose the host computer issues a command to "light up segment 1 of the light strip", with frame sequence number 0x15. If this command is retransmitted due to a communication error, the peripheral device can detect that the command has already been executed by checking frame sequence number 0x15. It will then directly return the previous ACK without repeating the lighting operation, thus ensuring idempotency of the command and preventing the light strip from flickering or malfunctioning.

[0073] In this embodiment, by executing the idempotency and deduplication control process, the operation of peripheral devices can be kept consistent and secure in the presence of communication jitter, command retransmission or network out-of-order issues, while reducing redundant operations and improving the overall operating efficiency of the system.

[0074] This application provides a device capability self-description and negotiation method. By actively issuing device access commands when peripheral devices are powered on, the host computer can obtain the types and quantities of peripheral devices actually existing in the system in real time, achieving rapid identification of peripheral devices. Based on a unified standard frame, the method acquires the status and capability information of each peripheral device, realizing a structured expression of device operating parameters and controllable ranges, providing a basis for subsequent unified control. By automatically generating control command templates, the host computer does not need to maintain multiple sets of adaptation logic for different peripheral devices, achieving cross-device reuse of command formats and control strategies, significantly reducing system expansion and... Operational costs are reduced; constraint and conflict checks are performed before instructions are issued, and conflict resolution processes are executed when necessary to ensure safe execution of instructions under parameter boundaries, mutual exclusion conditions, resource and energy consumption constraints, and time constraints, thereby improving system stability; in the event of communication or execution anomalies, a non-blocking compatibility degradation process is adopted to enable the system to continue operating in mixed-model or heterogeneous peripheral environments; unified management of the health status of peripherals across different models is achieved through the reception, analysis, and event semantic standardization of health monitoring data; idempotency and deduplication control based on standard frame sequence numbers ensures that duplicate or out-of-order instructions do not lead to duplicate operations or abnormal states. In summary, this application can achieve automatic identification of peripheral devices, unified capability description, automatic generation of instruction templates, safe execution of controlled instructions, and unified management of health status, thereby significantly improving the scalability, compatibility, and operational stability of the robot system in multi-device and multi-model environments.

[0075] Based on the device capability self-description and negotiation method provided in the above embodiments, this application further provides a device capability self-description and negotiation apparatus. Please refer to... Figure 4 , Figure 4 This is a structural diagram of the device's self-describing and negotiation capability mechanism. For example... Figure 4 As shown, the device capability self-description and negotiation device 200 includes: a target device list information acquisition module 210, a device detailed information acquisition module 220, a control command template generation module 230, and a target execution command selection and execution module 240.

[0076] The target device list information acquisition module 210 is used to send device access commands to each peripheral device when each peripheral device is powered on, so that each peripheral device returns the target device list information to the host computer according to the device access commands; the device information acquisition module 220 is used to send device information acquisition commands to each peripheral device according to the target device list information, so that each peripheral device returns the corresponding status information and capability information to the host computer according to the device information acquisition commands; the control command template generation module 230 is used to generate control command templates according to the status information and capability information corresponding to each peripheral device; the target execution command selection and execution module 240 selects the target execution command according to the control command template and the preset verification strategy, and sends the target execution command to each peripheral device, so that each peripheral device returns the execution feedback result to the host computer according to the target execution command; wherein, the device access command, the device information acquisition command, and the target execution command are sent through standard frames.

[0077] It should be noted that the aforementioned device capability self-description and negotiation apparatus can execute the device capability self-description and negotiation method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the device capability self-description and negotiation apparatus can be found in the device capability self-description and negotiation method provided in the embodiments of this application.

[0078] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions. These instructions are executed by one or more processors to enable at least one processor to perform the device capability self-describing and negotiation method described in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0079] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A device capability self-description and negotiation method, applied to a host computer, wherein the host computer and various peripheral devices communicate via a preset standard frame, characterized in that... The method includes: When each of the peripheral devices is powered on, a device access command is sent to each of the peripheral devices, so that each of the peripheral devices returns the target device list information to the host computer according to the device access command; Based on the target device list information, a device information acquisition instruction is sent to each of the peripheral devices, so that each peripheral device returns its corresponding status information and capability information to the host computer according to the device information acquisition instruction; Based on the status information and capability information corresponding to each of the peripheral devices, a control instruction template is generated; According to the control instruction template and the preset verification strategy, a target execution instruction is selected and sent to each of the peripheral devices, so that each of the peripheral devices returns the execution feedback result to the host computer according to the target execution instruction; The device access command, the device information acquisition command, and the target execution command are sent through the standard frame.

2. The equipment capability self-description and negotiation method according to claim 1, characterized in that, The standard frame format includes a frame version number, message type number, three-level addressing field, frame sequence number, length, data area, and frame checksum.

3. The equipment capability self-description and negotiation method according to claim 2, characterized in that, The three-level addressing domain includes the device type classification number of the peripheral device, the serial number of the peripheral device, and the instance number of the peripheral device.

4. The equipment capability self-description and negotiation method according to claim 1, characterized in that, The step of selecting the target execution instruction based on the control instruction template and the preset verification strategy includes: According to the control instruction template, obtain the device execution instruction; The instructions executed by the device are verified; When the device executes an instruction that satisfies the constraint verification condition, it is determined whether the device executes the instruction that satisfies the conflict verification condition. If the device execution instruction satisfies the conflict check condition, the device execution instruction shall be used as the target execution instruction; If the device executes an instruction that does not meet the conflict verification conditions, a conflict resolution process is executed.

5. The equipment capability self-description and negotiation method according to claim 1, characterized in that, The method further includes: When the host computer detects an abnormal situation during communication with or execution of instructions from the peripheral devices, it executes a non-blocking compatibility degradation process.

6. The equipment capability self-description and negotiation method according to claim 1, characterized in that, The method further includes: Receive health monitoring data reported by each of the peripheral devices; The health monitoring data is analyzed; If the health monitoring data is in an abnormal state range, the health monitoring data is standardized using a preset event semantic standardization processing strategy to obtain the target health data.

7. The equipment capability self-description and negotiation method according to claim 2, characterized in that, The method further includes: When the host computer sends the target execution instruction to each of the peripheral devices through the standard frame, it performs an idempotency and deduplication control process based on the frame sequence number carried in the standard frame.

8. A device for self-describing and negotiating equipment capabilities, characterized in that, The device includes: The target device list information acquisition module is used to send a device access command to each peripheral device when each peripheral device is powered on, so that each peripheral device returns the target device list information to the host computer according to the device access command; The device details acquisition module is used to send device information acquisition instructions to each of the peripheral devices according to the target device list information, so that each peripheral device returns its corresponding status information and capability information to the host computer according to the device information acquisition instructions; A control instruction template generation module is used to generate control instruction templates based on the status information and capability information corresponding to each of the peripheral devices. The target execution instruction selection and execution module selects a target execution instruction based on the control instruction template and a preset verification strategy, and sends the target execution instruction to each of the peripheral devices, so that each peripheral device returns an execution feedback result to the host computer based on the target execution instruction; wherein, the device access instruction, the device information acquisition instruction, and the target execution instruction are sent through standard frames.

9. A host computer, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by a host computer, cause the host computer to perform the method described in any one of claims 1-7.

Images