A control system and method for distributed robotic peripherals

Abstract

The embodiment of the present specification provides a kind of distributed robot peripheral control method and system, and main control module generates abstract semantic instruction based on business task data, and generates multiple organ level instructions according to the peripheral module information at least including state information reported by distributed peripheral module;Difference host module converts digital communication data into differential bus signal, and transmits organ level instruction and peripheral module information by communication bus transmitter;The organ level instruction is received in the slave microcontroller of distributed peripheral module and is converted into local control sequence, drives actuator action, and feedback state information in execution process and / or after ending.

Description

Technical Field

[0001] This specification relates to the field of robot control technology, and in particular to a control system and method for a distributed robot peripheral. Background Technology

[0002] With the diversification of robot forms and the increasing complexity of interactive functions, robot systems typically require control of various peripheral devices such as screens, servos, lighting modules, and sensors. In existing technologies, robot expansion devices mostly adopt a centralized control architecture, with the main control chip uniformly responsible for the underlying drivers, communication protocol processing, and execution logic control of the peripherals. In certain application scenarios, when the number of peripherals increases, the level of task concurrency rises, or different hardware platforms need to be adapted, this control method may place a high computational load on the main control chip and potentially increase the complexity of software architecture adjustments and system expansion. Therefore, it is necessary to improve aspects such as multi-peripheral collaborative control, cross-platform adaptation, and system flexibility.

[0003] Therefore, we hope to propose a control system and method for distributed robot peripherals to reduce the computational pressure and software complexity of the main control chip to a certain extent, and improve the scalability, real-time performance and stability of the robot system. Summary of the Invention

[0004] One embodiment of this specification provides a control system for distributed robot peripherals. The system includes: a master control module configured to: generate abstract semantic instructions based on task data; generate multiple organ-level instructions based on peripheral module information reported by distributed peripheral modules and the abstract semantic instructions; the peripheral module information includes at least status information; a differential master module configured to convert digital communication data output by the master control module into differential bus signals; a communication bus module configured to transmit the organ-level instructions and the peripheral module information; and multiple distributed peripheral modules, each including a slave microcontroller and one or more actuators, configured to: report the peripheral module information to the master control module; the slave microcontroller configured to: receive the organ-level instructions transmitted via the communication bus module; convert the organ-level instructions into local control sequences; drive the actuators to perform corresponding actions based on the local control sequences; and feed back the status information to the master control module during and / or after the action execution.

[0005] One embodiment of this specification provides a control method for distributed robot peripherals. The method includes: receiving organ-level instructions from a main control module; wherein the organ-level instructions are generated by the main control module based on peripheral module information and abstract semantic instructions, and the abstract semantic instructions are generated based on business task data; the peripheral module information includes status information; converting the organ-level instructions into a local control sequence, driving an actuator to perform a corresponding action based on the local control sequence; and feeding back the status information to the main control module during and / or after the action execution. Attached Figure Description

[0006] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0007] Figure 1 This is a schematic diagram illustrating an application scenario of a control system for a distributed robot peripheral, based on some embodiments of this specification. Figure 2 This is an exemplary schematic diagram of a control system for a distributed robot peripheral according to some embodiments of this specification; Figure 3 This is an exemplary flowchart of a control method for a distributed robot peripheral according to some embodiments of this specification; Figure 4 This is an exemplary schematic diagram illustrating the assessment of overload risk according to some embodiments of this specification; Figure 5 These are exemplary schematic diagrams illustrating parameter range verification according to some embodiments of this specification; and Figure 6 These are exemplary schematic diagrams illustrating the monitoring of physical parameters according to some embodiments of this specification. Detailed Implementation

[0008] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0009] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0010] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0011] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0012] The application of distributed robot peripheral control systems can involve robots of various forms, types, and application fields. For example, it can include, but is not limited to: commercial service robots (such as food delivery robots, shopping mall / hotel welcoming and guiding robots, etc.), family companion robots, educational interactive robots, industrial collaborative robots, medical rehabilitation robots, logistics and warehousing robots, and special operation robots, etc.

[0013] It should be noted that the application scenarios and robot types described above are merely examples to aid in understanding the technical solutions in this specification. This specification does not impose any strict limitations on the specific form, structural features, size, or specific application industry of the robot. Those skilled in the art should understand that the technical solutions provided in the embodiments of this specification are applicable to any robot, intelligent equipment, or robot-like system that requires distributed collaborative control of multiple peripheral devices.

[0014] Figure 1 This is a schematic diagram illustrating an application scenario of a control system for a distributed robot peripheral, based on some embodiments of this specification. For example... Figure 1 As shown, the application scenario of the control system for distributed robot peripherals (hereinafter referred to as application scenario 100) may include business sending terminal 110, network 120, control system 130 of distributed robot peripherals (hereinafter referred to as control system 130) and user 140.

[0015] In some embodiments, such as Figure 1As shown, the business dispatch terminal 110 can be configured as the robot's upstream behavior decision-making system, cloud service interface, or local human-computer interaction algorithm module. The business dispatch terminal 110 can run independently or be embedded in the robot's central control program. It is used to generate and output business task data describing the robot's overall behavioral intent, application scenario functions, or macro-level interaction goals based on current human-computer interaction needs, changes in the external environment, or received remote commands. For example, this business task data may include macro-level behavioral control task packages such as "greeting the user," "responding with surprise," or "performing obstacle avoidance interaction." For more information on business task data, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0016] Network 120 may include one or more of wired networks, wireless networks, or local internal communication links. For example, wireless networks may include wireless local area networks (Wi-Fi), Bluetooth, cellular mobile communication networks (such as 5G or 6G networks), etc.; wired networks may include Ethernet, internal digital communication buses, etc. Network 120 is used to establish a stable and reliable data transmission channel between the service sending end 110 and the control system 130 of the distributed robot peripherals, thereby transmitting the business task data generated by the service sending end 110 to the control system 130 of the distributed robot peripherals in real time and accurately.

[0017] The control system 130 for distributed robot peripherals (hereinafter referred to as the control system 130) can be deployed or integrated inside the robot body. In some embodiments, the control system 130 may include a main control module 131, a differential host module 132, a communication bus module 133, and multiple distributed peripheral modules 134. After receiving business task data, the control system 130 generates abstract semantic instructions through the main control module 131, which are then converted into multiple organ-level instructions with specific receiving addresses. These instructions are then converted into differential bus signals by the differential host module 132 and transmitted to each distributed peripheral module 134 via the communication bus module 133. This allows each distributed peripheral module 134 to independently complete hardware driving and closed-loop feedback locally. For more information about the control system 130, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0018] User 140 can refer to an external interaction object, operator, or human individual or other biological individual in the robot's operating environment who interacts with the robot through physical actions, visual interactions, or voice interactions. User 140 can trigger behavioral decisions of the business terminal 110 through gestures, voice, or facial expressions, and acts as the receiver and experiencer of the robot's interactive performance. For example, when the robot performs an atomic action or visual expression to "greet the user," user 140 can directly perceive the robot's limb movements, changes in screen expressions, or sound effects.

[0019] In some embodiments, the interaction of the various components in application scenario 100 may include: the business dispatch terminal 110 can generate business task data according to the interaction needs with user 140 or preset behavior scheduling rules, and send the business task data to the control system 130 through network 120; the main control module 131 inside the control system 130 receives the business task data and can generate abstract semantic instructions based on the business task data; the main control module 131 can further combine the peripheral module information reported by each distributed peripheral module 134 to generate multiple organ-level instructions, which are converted into differential bus signals by differential host module 132 and transmitted to the corresponding distributed peripheral module 134 through communication bus module 133; after receiving their respective organ-level instructions, each distributed peripheral module 134 converts them into corresponding local control sequences and drives the actuator to perform corresponding actions based on the local control sequences, thereby presenting a highly coordinated overall interaction effect to user 140. Meanwhile, during or after the execution of an action, each distributed peripheral module 134 will also transmit the current dynamic status information back to the main control module 131 through the communication bus module 133, so that the main control module 131 can dynamically correct the subsequent task scheduling.

[0020] The following is combined with Figure 2 The control system 130 for the distributed robot peripherals is further explained.

[0021] Figure 2 This is an exemplary schematic diagram of a control system for a distributed robot peripheral according to some embodiments of this specification.

[0022] In some embodiments, such as Figure 2As shown, the control system 130 for distributed robot peripherals includes: a main control module 131, configured to: generate abstract semantic instructions based on business task data; generate multiple organ-level instructions based on peripheral module information and abstract semantic instructions reported by distributed peripheral modules 134; the peripheral module information includes at least status information; a differential host module 132, configured to convert digital communication data output by the main control module 131 into differential bus signals; a communication bus module 133, configured to transmit organ-level instructions and peripheral module information; and multiple distributed peripherals. Module 134, the distributed peripheral module 134 includes a slave microcontroller 1341 and one or more actuators 1342. The distributed peripheral module 134 is configured to: report peripheral module information to the master control module 131; the slave microcontroller 1341 is configured to: receive organ-level instructions transmitted via the communication bus module 133; convert the organ-level instructions into local control sequences, drive the actuators 1342 to perform corresponding actions based on the local control sequences; and provide feedback status information to the master control module 131 during and / or after the action execution.

[0023] In some embodiments, the main control module 131 generates abstract semantic instructions based on business task data.

[0024] The main control module 131 refers to the core control unit in the control system that is responsible for control decisions and module coordination. For example, the main control module 131 can be a central processing unit, a microprocessor, or a system-on-a-chip.

[0025] Business task data refers to control task packages issued by the business dispatcher 110, which describe the robot's overall behavioral intent, application scenario functions, or macro-level interaction goals. For example, business task data can be scene interaction commands at the robot level, such as "greeting the user," "responding with surprise," or "performing obstacle avoidance movement along a specific trajectory." In some embodiments, the user can trigger the behavior decision of the business dispatcher 110 through gestures, voice, or facial expressions. The business dispatcher 110 uses a local human-computer interaction algorithm module to analyze and match the user's interaction characteristics, thereby generating corresponding business task data. For example, when the visual algorithm recognizes the user waving, it generates business task data for "greeting the user." In some embodiments, the business dispatcher 110 can also receive remote instructions from a cloud service interface or a remote server via the network, and convert and encapsulate these remote instructions into business task data packets that the robot system can recognize.

[0026] Abstract semantic instructions are high-level control instructions used to express the intention, type, and related parameters of an action. For example, an abstract semantic instruction may include the action type, intensity parameter, and duration parameter. An abstract semantic instruction could represent happiness, greeting, or widening one's eyes.

[0027] In some embodiments, after receiving business task data, the main control module 131 can select a corresponding template from the preset semantic template library based on the business task data to generate an abstract semantic instruction containing action category, intensity parameter and duration parameter.

[0028] A pre-built semantic template library refers to a structured data collection containing mapping relationships between business task scenarios and abstract semantic instructions. These mapping relationships can take the form of index tables, relation matrices, or key-value pairs, associating specific business task data with one or more sets of corresponding abstract semantic instructions. For example, in a welcoming pre-built semantic template, the mapping relationship can map business task data to abstract semantic instructions such as the voice module playing a welcome message, the arm module waving, and the screen module displaying a smiley face, along with their associated timing sequences. The pre-built semantic template library can be statically orchestrated by technical personnel based on typical human-computer interaction scenarios and permanently stored in the non-volatile memory of the main control module 131.

[0029] Intensity parameters are level labels used to quantitatively characterize the amplitude, speed, and force of an action's intent. For example, for a waving motion, intensity parameters can be divided into multiple levels, with low levels indicating a slight, slow wave and high levels indicating a rapid, large wave.

[0030] In some embodiments, the main control module 131 can also parse the verb, object and scene fields in the business task data based on the rule engine, generate one or more abstract semantic instructions according to the preset mapping relationship, and attach priority and other tags to each abstract semantic instruction.

[0031] In some embodiments, abstract semantic instructions can also be generated in other ways. For example, the main control module 131 looks up a table based on a pre-set scenario script library to directly map the business task identifier to a set of abstract semantic instructions.

[0032] In some embodiments, the main control module 131 generates multiple organ-level instructions based on the peripheral module information and abstract semantic instructions reported by the distributed peripheral module 134, wherein the peripheral module information includes at least status information.

[0033] The distributed robot peripheral control system 130 refers to a control system that performs distributed management, communication, and collaborative control of multiple robot peripherals. For example, robot peripherals may include displays, servo joints, speakers, robotic arms, or vibrators.

[0034] The distributed peripheral module 134 refers to a peripheral function (such as physical interaction such as motion, display, and sound) unit used to implement local functions of the robot and capable of independently responding to control. For example, the distributed peripheral module 134 may include a display module, a motion joint module, or an audio module.

[0035] Peripheral module information refers to a structured data set used to describe the physical attributes, hardware configuration, capability range, and operating status of the distributed peripheral module 134. For example, peripheral module information may include module identifier, module type, capability information, parameter range, and status information.

[0036] During the research, calibration, and production phases of the distributed peripheral module 134, technicians can pre-write the module identifier, module type, and capability information of the distributed peripheral module 134 into its flash memory. The parameter ranges in the peripheral module information can be obtained and written into the flash memory through finite element analysis, thermal resistance simulation, and destructive overload testing during the design verification phase.

[0037] A module identifier is a digital physical code that uniquely identifies and marks the 134 nodes of the distributed peripheral module. For example, a module identifier can be specifically represented as a globally unique 128-bit physical identifier that is embedded in the flash memory of the distributed peripheral module 134 at the factory.

[0038] Module type refers to a static label used to characterize the hardware functional category or device configuration attribute to which the distributed peripheral module 134 belongs. For example, module types can be quantitatively distinguished using specific hexadecimal feature codes, where code 0x01 represents a joint module such as a motion axis, motor, or servo, and code 0x02 represents a display screen module such as an LCD or light-emitting array.

[0039] Capability information refers to the list of all atomic action names and supported abstract semantic instruction sets that the distributed peripheral module 134 can parse and execute independently locally. For example, capability information can be represented as a list of functional interfaces, which explicitly lists the atomic action codes such as "waving", "nodding", "reset", and "perform slight jitter" that the module can support and translate locally.

[0040] The parameter range refers to the extreme physical constraints and boundary conditions that allow the internal hardware of the distributed peripheral module 134 or the actuator 1342 to operate under safe conditions. For example, the parameter range can specifically be expressed as the maximum current limit that the actuator 1342 is allowed to consume when performing an action, the angular range boundary of the linkage mechanism during movement, the maximum rotational speed range of the motor, and the screen brightness limit range that the display device is allowed to adjust, etc.

[0041] Status information refers to information used to characterize the current operating status or action feedback of the distributed peripheral module 134. For example, status information may include idle status, busy status, action start status, action completion status, action failure status, or abnormal status.

[0042] Organ-level instructions refer to execution instruction data that are targeted at a specific peripheral module and have a target object and execution parameters. For example, organ-level instructions may include target module identifier, target module role, action command type, action parameters, action start time, action duration, action speed level, action priority, action synchronization flag, action interruption policy, security restriction parameters, etc.

[0043] The target module identifier refers to the unique hardware address of the specific distributed peripheral module 134 to which the organ-level instruction is to be sent. The target module role refers to the logical functional division of the distributed peripheral module 134 to which the organ-level instruction is to be sent within the robot body. The action command type refers to the name or function code feature of the specific atomic action that the distributed peripheral module 134 needs to execute locally. The action parameters refer to the specific target values ​​used to quantify the amplitude and degree of the action indicated by the organ-level instruction. The action start time, i.e., the execution timestamp, refers to the start time marker used to align the action indicated by the organ-level instruction on the timeline, used to control the sequence of coordinated actions of multiple organs (actuators). The action duration refers to the total physical time allowed for the action to take from initiation to complete stillness.

[0044] Action speed level refers to the physical movement rate level at which an action is required to be executed. Action priority refers to the urgency level of an action. Action synchronization flag is a synchronization enable signal indicating whether an action needs to be synchronized with the actions of other distributed peripheral modules 134. Action interruption policy refers to the processing rules for how currently unfinished actions should safely exit when a distributed peripheral module 134 receives a new high-priority instruction or triggers local non-fatal protection. Safety limit parameters refer to the maximum power quota or communication frequency quota dynamically allocated by the main control module 131 to the distributed peripheral module 134 for degradation protection based on the current overall system energy consumption pressure and bandwidth load.

[0045] In some embodiments, each distributed peripheral module 134 enters the registration state after power-on and sends a registration message (i.e., peripheral module information) containing module identifier, module type, capability information, parameter range and status information to the main control module 131.

[0046] In some embodiments, the main control module 131 can perform global action orchestration on abstract semantic instructions to generate multiple organ-level instructions. The global action orchestration includes at least one or more of the following: multi-module synchronous triggering, serial action orchestration, priority scheduling, mutual exclusion control, action retry or replacement, and state-aware scheduling.

[0047] Among them, multi-module synchronous triggering refers to multiple distributed peripheral modules 134 starting to execute their respective actions under a unified time base; serial action orchestration refers to the next distributed peripheral module 134 being triggered after the previous distributed peripheral module 134 has completed its execution; priority scheduling refers to critical actions being executed before decorative actions; mutual exclusion control refers to the actions of distributed peripheral modules 134 that may cause mechanical interference, power consumption conflicts, or logical conflicts not being executed simultaneously; action retry or replacement refers to other distributed peripheral modules 134 filling in or performing degraded actions when a distributed peripheral module 134 is offline or refuses to execute; and state-aware scheduling refers to dynamically correcting subsequent tasks based on the busy / idle status, execution completion status, and abnormal status reported by the distributed peripheral modules 134.

[0048] For example, the main control module 131 can decompose the abstract semantic instruction of "surprise response" into: sending an organ-level instruction to the audio module to "play sound effect", sending an organ-level instruction to the screen module in the distributed peripheral module 134 to "open eyes wide", and sending an organ-level instruction to the robotic arm module to "shortly lift". These organ-level instructions are synchronously issued by the main control module 131 according to a unified time base and are executed independently locally by each distributed peripheral module 134.

[0049] For example, after receiving the abstract semantic instruction, the main control module 131 can call the internal semantic parsing engine to decompose the macroscopic interaction intent into multiple basic atomic action requirements that are independent of each other in physical space and execution logic. The main control module 131 queries the locally dynamically maintained global peripheral resource registry, and combines the capability information and module type in the peripheral module information pre-reported by each distributed peripheral module 134 to accurately address and map the decomposed basic atomic action requirements to the corresponding distributed peripheral module 134, thereby establishing the target module identifier and specific action command type of the distributed peripheral module 134 corresponding to each instruction to be generated.

[0050] Subsequently, the main control module 131 executes timing alignment and resource scheduling logic. On a unified global time reference axis, the main control module 131 assigns precise start times and durations to each atomic action, and ensures strict coordination and alignment of multiple heterogeneous distributed peripheral modules 134 (such as display screens and robotic arms) at the physical level by configuring action synchronization markers. At the same time, based on the magnitude of the action parameters, combined with the current global power budget and remaining bandwidth of the communication bus, the main control module 131 dynamically calculates and assigns corresponding action speed levels, action priorities, action interruption strategies, and safety limit parameters to each action.

[0051] Finally, the main control module 131 performs structured combination and packaging of all the control fields determined by the above calculations according to the underlying communication protocol standard, thereby generating multiple organ-level instruction data packets with clear receiving addresses, complete execution boundaries and strict timing constraints, thus completing the conversion from high-level abstract semantics to microscopic physical nodes and global orchestration.

[0052] In some embodiments, organ-level instructions can also be generated in other ways. For example, the main control module 131 directly maps abstract semantic instructions and peripheral module information to a set of organ-level instructions corresponding to the target module identifier based on a static configuration table and state thresholds.

[0053] In some embodiments, the differential host module converts the digital communication data output by the main control module 131 into differential bus signals.

[0054] A differential master module is an interface conversion module used to convert digital communication data into differential transmission signals. For example, a differential master module can be a bus interface conversion circuit.

[0055] Digital communication data refers to structured command data, status request data, or configuration data generated internally by the main control module 131. The structured command data may include the aforementioned organ-level instructions. Before being transmitted via the differential host module, the digital communication data is in logic level and digital frame format.

[0056] Differential bus signals refer to physical layer signals transmitted on a communication bus using a differential method. For example, differential bus signals can be two-wire differential level signals.

[0057] In some embodiments, the differential host module can receive serial port data or on-chip bus data output by the main control module 131, perform frame encapsulation and verification processing on the digital communication data, and then convert the logic level signal into a balanced two-wire differential level signal through the differential drive circuit and output it to the communication bus module 133.

[0058] In some embodiments, the differential master module can also perform the conversion in other ways. For example, the differential master module performs line-driven shaping on the digital communication data according to preset physical layer electrical constraints and then outputs a differential bus signal.

[0059] In some embodiments, the communication bus module 133 can transmit organ-level instructions and peripheral module information.

[0060] The communication bus module 133 refers to a data transmission module used to enable bidirectional communication between the differential host module and multiple distributed peripheral modules 134. For example, the communication bus module 133 can be a twisted-pair communication bus shared by multiple nodes.

[0061] In some embodiments, the communication bus module 133 adopts a multi-node shared twisted-pair topology, transmitting organ-level command messages in the downlink direction and transmitting peripheral module information actively reported or passively responded to by each distributed peripheral module 134 in the uplink direction.

[0062] In some embodiments, the communication bus module 133 may also divide the sending window and the feedback window according to a preset time window in order to maintain the consistency and timing of bus message transmission.

[0063] In some embodiments, the distributed peripheral module 134 reports peripheral module information to the main control module 131.

[0064] In some embodiments, bidirectional data interaction between the distributed peripheral module 134 and the communication bus module 133 is achieved through an internally integrated bus transceiver 1343. For more information about the bus transceiver 1343, please refer to [link to relevant documentation]. Figure 6 And its related descriptions.

[0065] The slave microcontroller 1341 refers to a microcontroller unit used for instruction parsing, local control generation, actuator drive control, and status feedback. For example, the slave microcontroller 1341 can be a single-chip microcomputer or an embedded microprocessor chip within the distributed peripheral module 134.

[0066] In some embodiments, after the distributed peripheral module 134 is powered on, the slave microcontroller 1341 reads the static configuration data in the local flash memory and encapsulates the module identifier, module type, capability information, parameter range and initial state information into a registration message (i.e. peripheral module information), which is then sent to the master control module 131 via the communication bus module 133.

[0067] In some embodiments, each distributed peripheral module 134 may also integrate a power management circuit. The power management circuit can be used to dynamically modulate the system power provided by the communication bus module 133 or the bus network into the operating power required for the local microcontroller and actuator 1342 to run. Depending on the different hardware functional divisions, the distributed peripheral module 134 can take on various specific physical forms.

[0068] For example, when the distributed peripheral module 134 is a display-type peripheral module, the internal actuator 1342 is specifically manifested as a liquid crystal display (LCD), which is driven by the slave microcontroller 1341 through a serial peripheral interface (SPI) or a parallel interface to display facial expressions or animation materials; when the distributed peripheral module 134 is a motion-type peripheral module, the internal actuator 1342 is specifically manifested as a servo motor or an electromagnetic motor, which is controlled by the slave microcontroller 1341 to generate physical motion by outputting a pulse width modulation signal or a corresponding drive pulse signal; when the distributed peripheral module 134 is a haptic feedback-type peripheral module, it integrates a vibration or touch device as an actuator 1342, which is sampled by the slave microcontroller 1341 in real time and controls the actuator 1342 to output corresponding physical vibration feedback.

[0069] In some embodiments, the distributed peripheral module 134 may also proactively report status changes according to the heartbeat cycle after registration and reporting, or return updated peripheral module information after receiving a polling request from the main control module 131.

[0070] In some embodiments, the slave microcontroller 1341 receives organ-level instructions transmitted via the communication bus module 133.

[0071] In some embodiments, the slave microcontroller 1341 can continuously listen to the bus messages transmitted on the communication bus module 133. When it is found that the target module identifier carried in the message matches the module identifier configured in itself, it immediately triggers a hardware receive interrupt and extracts and locks the corresponding organ-level instruction in the local receive buffer.

[0072] In some embodiments, the slave microcontroller 1341 may also adopt a polling reception method to read organ-level instructions from the receive buffer queue and complete message verification.

[0073] In some embodiments, the slave microcontroller 1341 can convert organ-level instructions into local control sequences, and drive the actuator 1342 to perform corresponding actions based on the local control sequences.

[0074] Actuator 1342 refers to a drive component used to directly output mechanical motion, optical effects, acoustic effects, force feedback, or other physical properties. For example, actuator 1342 may include a motor, servo motor, display, speaker, or vibrating device.

[0075] A local control sequence refers to a set of control data used to instruct the actuator 1342 to perform actions in a time sequence. For example, a local control sequence may include a pulse width modulation (PWM) waveform, a screen refresh frame sequence, a brightness change curve, or a motor start / stop curve.

[0076] In some embodiments, the slave microcontroller 1341 calls the local command interpreter to query the action mapping table and maps the action command type, action parameters and action start time in the organ-level instructions to a pre-stored local execution scheme.

[0077] An action mapping table is a data table that maps abstract semantic commands to a set of underlying execution process relationships that the distributed peripheral module 134 can understand. For example, for a display-type peripheral module, the action mapping table can map the "happy" command to a specific expression material sequence, the "dizzy" command to a rotating eye animation sequence, and the "speaking" command to a multi-frame mouth shape change animation; for a motion-type servo motor module, the action mapping table can map the "wave" command to reciprocating swing data within a preset angle range, the "startled" command to a short-term jitter waveform after a rapid lift, and the "reset" command to a position control quantity that returns to zero and maintains or disables the output.

[0078] The slave microcontroller 1341 can generate a local control sequence for the corresponding actuator 1342 based on the queried execution scheme. For example, it can generate specific pulse width modulation waveforms, screen refresh frame sequences, brightness change curves, or motor start-stop curves.

[0079] In some embodiments, the slave microcontroller 1341 can also perform trajectory generation or parameter interpolation based on the action parameters, duration and safety limit parameters in the organ-level instructions, generate motor start-stop curves, position curves or vibration timing curves in real time, and drive the actuator 1342 to output local actions consistent with the abstract semantics according to the configuration and constraints of this module.

[0080] In some embodiments, the local control sequence can also be generated in other ways. For example, the slave microcontroller 1341 splices multiple action segments based on a finite state machine and outputs the timing control quantity corresponding to the actuator 1342.

[0081] For more information on how to drive actuator 1342 to perform corresponding actions, please refer to [link / reference needed]. Figure 3 And its related descriptions.

[0082] In some embodiments, the distributed peripheral module 134 feeds back status information to the main control module 131 during and / or after the execution of an action. For more information on this, please refer to [link to relevant documentation]. Figure 3 And its related descriptions.

[0083] In some embodiments, such as Figure 2 As shown, in addition to the slave microcontroller 1341 and actuator 1342, the distributed peripheral module 134 may also include a bus transceiver 1343, a current detection unit 1344, an encoder 1345, an inertial measurement unit 1346, a parameter sensor 1347, and an angle encoder 1348. For more information on the current detection unit 1344 and the encoder 1345, please refer to [link to relevant documentation]. Figure 5 And its related descriptions. For more information on the bus transceiver 1343, parameter sensor 1347, and angle encoder 1348, please refer to... Figure 6 And its related descriptions.

[0084] In actual operation, the main control module 131 first generates abstract semantic instructions based on business task data, and combines this with the peripheral module information pre-reported by each distributed peripheral module 134 to decompose and arrange the abstract semantic instructions into multiple organ-level instructions. The digital communication data output by the main control module 131 is converted into differential bus signals by the differential host module 132, and then transmitted to each distributed peripheral module 134 through the communication bus module 133. At the distributed peripheral module 134 end, the bus transceiver 1343 is responsible for completing the underlying signal conversion to ensure smooth communication. After receiving the organ-level instructions, the slave microcontroller 1341 generates a local control sequence to drive the actuator 1342 to output physical actions. During this process, the current detection unit 1344, encoder 1345, angle encoder 1348, and inertial measurement unit 1346 work together to monitor the real-time motion status of the actuator 1342, while the parameter sensor 1347 continuously collects physical parameters such as temperature or current. The slave microcontroller 1341 uses this underlying data to perform autonomous action calibration and basic safety protection locally, and feeds back the status information to the master control module 131 during and / or after the action is executed, thus forming a complete distributed collaborative control closed loop of intention issuance, local execution and status feedback.

[0085] The control system for distributed robot peripherals provided in some embodiments of this specification achieves deep decoupling between high-level interaction logic and low-level hardware drivers by constructing a layered architecture based on the intention orchestration of the main control module and the local execution of the distributed peripheral modules. The main control module is only responsible for the global mapping and distribution of abstract semantic instructions to organ-level instructions, stripping away the heavy task of calculating low-level physical drive control waveforms, freeing up core computing resources and simplifying the software complexity of the main control program. At the same time, the distributed peripheral modules utilize their internal slave microcontrollers to autonomously convert organ-level instructions into specific local control sequences to drive actuator actions. This not only endows heterogeneous hardware with strong modular expansion and compatibility capabilities, but also reduces the high-frequency low-level data interaction bandwidth of the communication bus module, effectively avoiding bus congestion and control latency when multiple peripherals operate concurrently.

[0086] Figure 3 This is an exemplary flowchart of a control method for a distributed robot peripheral according to some embodiments of this specification. Figure 3 As shown, the flow 200 of the control method for the distributed robot peripheral includes steps 210 to 230. In some embodiments, the control method flow 200 for the distributed robot peripheral can be executed by a slave microcontroller 1341.

[0087] Step 210: Receive organ-level instructions from the main control module.

[0088] Among them, organ-level instructions are generated by the main control module 131 based on peripheral module information and abstract semantic instructions, and the abstract semantic instructions are generated based on business task data; peripheral module information includes status information.

[0089] For information on organ-level instructions, main control module 131, peripheral module information, abstract semantic instructions, business task data, and status information, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0090] Step 220: Convert organ-level instructions into local control sequences, and drive the actuator to perform corresponding actions based on the local control sequences.

[0091] During the drive execution phase, the drive circuit inside the slave microcontroller 1341 outputs a high-frequency complementary pulse width modulation signal (e.g., a 20 kHz drive signal) according to the local control sequence, which directly drives the actuator 1342 to work.

[0092] For more information on local control sequences and actuator 1342, please refer to [link / reference]. Figure 2 And its related descriptions.

[0093] Step 230: During and / or after the execution of the action, report status information to the main control module.

[0094] Status information refers to relevant data that reflects the progress and results of an action, including whether the action is completed, any abnormal situations that occur during the execution process, and the final state of the action.

[0095] In some embodiments, the slave microcontroller 1341 returns a receipt confirmation after receiving an organ-level instruction, returns an action start state when the action officially begins, feeds back the current action progress at a preset cycle during the action execution, and returns an action completion state after the action ends.

[0096] In some embodiments, when the slave microcontroller 1341 detects a stall, timeout, limit, excessive temperature rise, or insufficient power supply, it feeds back abnormal status information to the master control module 131 and first executes local protection measures such as speed reduction, shutdown, or exiting the current action.

[0097] In some embodiments, status information can also be fed back in other ways. For example, the slave microcontroller 1341 reports the current action progress and fault codes according to the feedback window period.

[0098] The control method for distributed robot peripherals provided in some embodiments of this specification allows the distributed peripheral module to directly convert organ-level instructions into local control sequences to drive actuator actions. This not only effectively shortens the latency of the underlying hardware action response, but also, combined with a rigorous closed-loop state information feedback mechanism, significantly improves the overall execution efficiency, real-time operation performance, and action reliability of the robot system under highly collaborative and interactive conditions of multiple peripherals.

[0099] In practical scenarios involving concurrent control of multiple peripherals in robots, if multiple distributed peripheral modules 134 simultaneously initiate high-load actions, it may lead to data congestion on the communication bus or cause a momentary overload of the system power grid, resulting in a voltage drop. In order to effectively improve the overall load limit and operational safety of the system without changing the overall hardware rated power and physical communication medium, the main control module 131 performs forward-looking overload risk prediction and adjustment before issuing organ-level commands.

[0100] Figure 4 This is an exemplary schematic diagram illustrating overload risk assessment according to some embodiments of this specification.

[0101] In some embodiments, the peripheral module information further includes a power consumption timing feature spectrum 410 and a bandwidth occupancy feature spectrum 420 corresponding to the actions of the distributed peripheral module 134. The main control module 131 is also configured to: determine the power prediction value 430 and bandwidth prediction value 440 of multiple organ-level instructions 450 at each time step based on the power consumption timing feature spectrum 410 and the bandwidth occupancy feature spectrum 420; determine whether there is an overload risk at each time step based on the bandwidth prediction value 440 and the power prediction value 430; and, in response to the existence of an overload risk at a certain time step, rearrange the abstract semantic instructions until there is no overload risk at that time step.

[0102] For more information on peripheral module information, distributed peripheral module 134, main control module 131, organ-level instructions 450, and abstract semantic instructions, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0103] The actions of the distributed peripheral module 134 refer to the specific behavioral functions that the distributed peripheral module 134 can perform. For example, shaking hands, waving, playing a specific facial animation sequence, or outputting vibration feedback at a specific frequency.

[0104] The power consumption timing characteristic spectrum 410 refers to a data set used to characterize the relationship between power consumption and time during the execution of a certain action. For example, the power consumption timing characteristic spectrum 410 can be discrete timing data formed by the change of current value with timestamps. It can be represented as .in, For timestamps, This corresponds to the current value.

[0105] The bandwidth occupancy feature spectrum 420 refers to a set of data characterizing the relationship between communication resource occupancy and time changes during the execution of a certain action. For example, the bandwidth occupancy feature spectrum 420 can be discrete data formed by the change of the number of packets per unit time with the timestamp. It can be represented as .in, For timestamps, This represents the corresponding number of messages.

[0106] It is understandable that different types of actions will dynamically occupy the robot's power resources and communication bus resources to varying degrees during execution. That is, different actions each contain their own corresponding and independent power consumption timing characteristic spectrum 410 and bandwidth occupancy characteristic spectrum 420.

[0107] In some embodiments, under a standard supply voltage (e.g., 12 volts), a precision digital power analyzer and an oscilloscope can be used to continuously collect the instantaneous operating current of the distributed peripheral module 134 when it performs each action, thereby forming a power consumption timing characteristic spectrum 410. Simultaneously, a bus protocol analyzer can be used to count the average number of message frames pushed to the communication bus module 133 per unit time (e.g., every 100 milliseconds) during the execution of this action, thereby generating a bandwidth occupancy characteristic spectrum 420. These two characteristic spectra, as binary resource packets, are directly embedded in the flash memory of the distributed peripheral module 134 during factory programming.

[0108] When generating peripheral module information, the distributed peripheral module 134 can directly query the flash memory and read the power consumption timing characteristic spectrum 410 and the bandwidth occupancy characteristic spectrum 420.

[0109] In some embodiments, the main control module 131 determines the power prediction value 430 and bandwidth prediction value 440 of multiple organ-level instructions 450 at each time step based on the power consumption timing feature spectrum 410 and the bandwidth occupancy feature spectrum 420.

[0110] The power prediction value of 430 refers to the maximum instantaneous total power that the robot's power supply system may withstand at a certain point in the future.

[0111] The bandwidth prediction value of 440 refers to the predicted proportion of bus load to its rated bandwidth at a certain future point in time.

[0112] In some embodiments, after generating multiple organ-level instructions 450, the main control module 131 reads the power consumption timing feature spectrum 410 and bandwidth occupancy feature spectrum 420 of the corresponding actions of each organ-level instruction 450, and determines the start time of each organ-level instruction 450 accordingly. The power consumption timing feature spectrum 410 and the bandwidth occupancy feature spectrum 420 are shifted along the time axis. This is done for each discrete sampling moment in the process of completing the entire abstract semantic instruction. The main control module 131 will schedule each concurrent action at a specific time. Sum the predicted current values ​​and then add them to the system voltage constant. Multiplying these values ​​yields a predicted power value of 430; the main control module 131 will schedule each concurrent action at a specific time. The number of packets is summed and added to the number of background packets to obtain the predicted number of packets at that moment. This predicted number of packets is then converted into a bandwidth occupancy ratio based on the system's rated bandwidth, resulting in a bandwidth prediction value of 440. Specifically, after receiving the organ-level instruction 450, the distributed peripheral module 134's internal slave microcontroller 1341 calls its local packet parsing program to directly extract the value carried in the action start time field and establishes this value as the proposed start-up timing. .

[0113] In some embodiments, power prediction values By using the system voltage constant At the same time point as each concurrent action The result is calculated by multiplying the sum of the predicted current values ​​after right shifting and translation. For example, .in, express Power prediction at any given time; This represents the system's voltage constant, which can be obtained by directly reading the locally preset value from the main control module 131; Indicates the sequence number of concurrent actions; Indicates the first The planned start time for each concurrent action; Indicates the first The predicted current value of each concurrent action can be obtained by the main control module 131 through the power consumption timing characteristic spectrum; Indicates the first The concurrent actions are shifted to the right along the timeline. Later The predicted current value generated at any given time.

[0114] In some embodiments, bandwidth prediction values By scheduling each concurrent action at a corresponding time point The sum of the number of messages after right shift and translation, plus the number of system-exclusive keep-alive background messages. The result is obtained by cumulative calculation.

[0115] In some embodiments, the bandwidth occupancy feature spectrum 420 pre-reported by the distributed peripheral module 134 records the number of packets to be sent within each relative time period after its own action is initiated. When evaluating global bandwidth, the main control module 131 considers any target moment on the global time axis... First, calculate the time relative to the target peripheral module's planned startup time. Local relative duration Subsequently, the main control module 131 uses this relative duration as an index to directly retrieve and map the number of message transmission frames in the corresponding interval within the bandwidth occupancy feature spectrum 420, thereby determining the module's global coverage. The bandwidth requirements at any given moment.

[0116] For example, .in, express Bandwidth prediction at any given time; Indicates the first The concurrent actions are shifted to the right along the timeline. Later The number of messages to be sent at any given time; Indicates that the system is in The number of always-on background messages can be obtained by counting the basic bus communication traffic when the system is in a static keep-on state, and then stored as a preset constant in the non-volatile memory of the main control module 131.

[0117] In some embodiments, the main control module 131 can also determine the power prediction value 430 and the bandwidth prediction value 440 through other means based on the power consumption timing characteristic spectrum 410 and the bandwidth occupancy characteristic spectrum 420. For example, the main control module 131 can first resample the power consumption timing characteristic spectrum 410 and the bandwidth occupancy characteristic spectrum 420 of each action at a unified sampling period, and then map each spectrum to a unified time grid according to the start timing of the organ-level instruction 450. Subsequently, the main control module 131 accumulates the current contribution and communication traffic contribution of concurrent actions in each time grid to obtain the power prediction value 430 and the bandwidth prediction value 440 at each time moment.

[0118] In some embodiments, the main control module 131 determines whether there is an overload risk at each time based on the bandwidth prediction value 440 and the power prediction value 430.

[0119] Overload risk refers to the risk state where the bandwidth prediction value 440 and / or power prediction value 430 exceed the system's allowable range.

[0120] In some embodiments, the main control module 131 compares the power prediction value 430 at each moment with the power supply safety threshold, and compares the bandwidth prediction value 440 at each moment with the bus carrying capacity threshold. When the power prediction value 430 at a certain moment is greater than the power supply safety threshold, or the bandwidth prediction value 440 is greater than the bus carrying capacity threshold, the main control module 131 determines that there is an overload risk at that moment.

[0121] In some embodiments, the main control module 131 can also determine whether there is an overload risk based on the bandwidth prediction value 440 and the power prediction value 430 in various ways. For example, the main control module 131 can calculate the load ratio of the power prediction value 430 relative to the power supply limit and the load ratio of the bandwidth prediction value 440 relative to the rated bandwidth, respectively; when either load ratio reaches or exceeds a preset risk ratio, the main control module 131 marks the corresponding time as a risk time with an overload risk.

[0122] For example, the main control module 131 queries the preset risk range table based on the power prediction value 430 and the bandwidth prediction value 440. When any prediction value falls into the over-limit range, it is determined that there is an overload risk.

[0123] In some embodiments, the main control module 131, in response to an overload risk at a certain moment, rearranges the abstract semantic instructions until there is no overload risk at that moment.

[0124] In some embodiments, the main control module 131 rearranges abstract semantic instructions by: while keeping the action target unchanged, sorting multiple abstract semantic instructions according to action priority, fixing the start time of high-priority actions, and shifting low-priority actions one by one to the back by a preset time slice. The main control module 131 recalculates the power prediction value 430 and bandwidth prediction value 440 at each time step after each shift. This process is repeated until the power prediction value 430 and bandwidth prediction value 440 at all times return to the allowable range. Then, it generates and sends messages based on the updated timing sequence. For more information on action priorities, please refer to [link to relevant documentation]. Figure 1 And its related descriptions.

[0125] In some embodiments, the main control module 131 may further include rearranging abstract semantic instructions by first identifying the action combination that causes resource conflict, and then, under the premise of satisfying the action dependency relationship, adjusting the start order of conflicting actions or inserting a delay interval so that the peak power segment and the peak bandwidth segment are staggered.

[0126] For example, when the main control module 131 detects that two actions requiring simultaneous access to memory and large amounts of data reading and writing could cause bandwidth overload, the main control module 131 can delay the start time of one of the actions by two clock cycles, thereby shifting its high bandwidth usage to another time period and avoiding overlap of power and bandwidth peaks. The main control module 131 re-determines the overload after each adjustment until there is no risk of overload.

[0127] In some embodiments, the rearrangement of abstract semantic instructions can also be achieved in other ways. For example, the main control module 131 serializes the conflicting actions with the highest resource consumption at the same time based on preset control logic to eliminate overlapping peaks.

[0128] In some embodiments described in this specification, the main control module performs strict timing alignment and synchronization mark configuration on a unified global time reference axis, ensuring a high degree of coordination in the physical interaction of multiple heterogeneous distributed peripheral modules and effectively eliminating the sense of disconnect between complex concurrent actions. Furthermore, the main control module dynamically assigns attributes and safety limit parameters to various actions based on the system's total global power budget and the remaining bandwidth of the communication bus. This prevents resource contention and instantaneous concurrent overload risks from the source of global scheduling, significantly improving the coherence of the robot's multimodal collaborative interaction and the overall safety of the system operation.

[0129] In some embodiments, in response to an overload risk at a certain moment, the main control module 131 is further configured to: when issuing organ-level instructions 450 to the target peripheral module, generate a resource quota for the target peripheral module based on the power prediction value 430 and the bandwidth prediction value 440, and issue the resource quota to the target peripheral module; the target peripheral module is configured to: limit the output amplitude, driving torque, or display brightness of the actuator 1342 based on the resource quota; send status information with high priority when the local change exceeds a preset threshold; and send a keep-alive short message when the local change is less than or equal to the preset threshold.

[0130] The target peripheral module refers to the distributed peripheral module 134 selected to perform the corresponding action. For example, in practical applications, if the distributed system contains multiple lighting modules, when the "turn on the lights" action needs to be performed, the lighting module located in room A can be selected as the target peripheral module, and that lighting module will perform the action of turning on the lights.

[0131] Resource quotas refer to resource limitation parameters allocated to target peripheral modules. In some embodiments, resource quotas can be used to constrain the power and / or communication resources that a target peripheral module is allowed to occupy during the current operating cycle. For example, resource quotas may include power quota coefficients and communication quota coefficients. For instance, when the total safe power allowed by the power system is eighty watts, and the total power required for normal operation of all currently active peripheral modules is one hundred watts, the resource quota may be a power quota coefficient of 0.8 issued by the master control module 131 to each peripheral module.

[0132] In some embodiments, the main control module 131 can obtain the power prediction value and bandwidth prediction value of each distributed peripheral module 134 in the current operation cycle, and add them together to obtain the sum of the power prediction value and the sum of the bandwidth prediction value; divide the total safe power budget by the sum of the power prediction values ​​to obtain the power quota coefficient; divide the total safe bandwidth budget by the sum of the bandwidth prediction values ​​to obtain the communication quota coefficient; write the power quota coefficient and the communication quota coefficient into the resource quota, and send them to the target peripheral module. The total safe power budget and the total safe bandwidth budget can be preset by technicians and stored in the non-volatile memory of the main control module 131.

[0133] In some embodiments, resource quotas can also be generated in other ways. For example, the main control module 131 can look up a table according to the overload level to obtain a preset power quota coefficient and a communication quota coefficient, and then associate the two coefficients with the target peripheral module before issuing them.

[0134] In some embodiments, the main control module 131 may limit the output amplitude, driving torque, or display brightness of the actuator 1342 based on resource quotas.

[0135] Output amplitude refers to the magnitude of the output signal or physical quantity of the actuator 1342. For example, the output amplitude can be the output voltage amplitude or the output current amplitude.

[0136] Drive torque refers to the magnitude of the torque output or allowed to be output by actuator 1342. For example, drive torque can be the output torque of a motor.

[0137] Display brightness refers to the intensity of light emitted by the display actuator 1342. For example, display brightness can be the screen backlight brightness or the brightness of the light-emitting device.

[0138] In some embodiments, the target peripheral module (or the slave microcontroller 1341 therein) can resolve the power quota coefficient in the resource quota; when the target peripheral module implements limit control locally, it will adjust the upper limit of the target driving torque in the original control sequence to the product of the power quota coefficient and the rated maximum torque.

[0139] In some embodiments, the target peripheral module can parse the power quota coefficient in the resource quota; set the display brightness limit to the product of the power quota coefficient and the rated maximum brightness; and then adjust the backlight current, duty cycle, or light emission drive level to make the display actuator work according to the adjusted brightness limit.

[0140] In some embodiments, limiting actuator output can also be achieved in other ways. For example, the target peripheral module can select a preset degradation mode based on resource quotas and adjust the upper limit of the actuator's allowed output according to the control logic corresponding to the degradation mode.

[0141] In some embodiments, the target peripheral module can also parse the communication quota coefficient or message transmission limit in the resource quota and accordingly impose local restrictions on the transmission frequency of status information. For example, the target peripheral module can adjust the status reporting period, limit the maximum number of frames sent per unit time, or compress the frequency of regular status reporting while meeting the high-priority status reporting requirements; when the local change does not meet the high-priority reporting conditions, the target peripheral module sends a keep-alive short message.

[0142] In some embodiments, when the target peripheral module's local change exceeds a preset threshold, it sends status data with high priority.

[0143] Local variation refers to the quantified value used to quantify the magnitude of changes in local feedback parameters or control parameters of a target peripheral module between adjacent sampling periods. For example, local variation can be the absolute value of the difference in position angular velocity fluctuations, the absolute value of current drift differences, or the absolute value of temperature change amplitude between two adjacent sampling periods (e.g., one millisecond). Local variation is obtained by the slave microcontroller 1341 continuously acquiring the sensor's feedback control parameters according to a set high-frequency period (e.g., one millisecond), and calculating the absolute value of the difference between the parameter value of the current sampling period and the parameter value of the adjacent previous sampling period.

[0144] A preset threshold refers to a pre-set comparison threshold used to determine whether a local change has reached a significant change condition. For example, the preset threshold can be a judgment benchmark such as a position angular velocity fluctuation threshold, a current drift threshold, or a temperature change rate limit. The preset threshold can be obtained during the R&D calibration phase by extracting the white noise standard deviation of the target sensor through high-frequency sampling in a static and interference-free standard environment. Then, three times this white noise standard deviation can be used as the preset threshold and directly embedded in the code and flash memory of the slave microcontroller 1341.

[0145] High priority refers to a priority level that has a higher processing order or higher transmission priority than regular tasks or regular messages.

[0146] In some embodiments, the target peripheral module can calculate the absolute value of the difference between position, speed, current or temperature related parameters between adjacent sampling periods according to the sampling period; compare each absolute value of the difference with its corresponding preset threshold; when any one of the absolute values ​​of the difference is greater than the corresponding preset threshold, immediately generate a status data message and write it into the transmission buffer with a higher transmission priority than the normal status reporting.

[0147] In some embodiments, the target peripheral module may also normalize the absolute value of the difference between the aforementioned multiple feedback parameters (position, temperature, current, etc.) to obtain a comprehensive local change; when the comprehensive local change exceeds a preset threshold, status data containing key status fields is immediately sent, and preemptive priority is adopted in bus arbitration.

[0148] In some embodiments, high-priority transmission of status data can also be achieved in other ways. For example, the target peripheral module can map status data to reserved message identifiers based on a fixed priority encoding rule, and directly trigger transmission when a threshold condition is met.

[0149] In some embodiments, the target peripheral module may send a keep-alive short message when the local change is less than or equal to a preset threshold.

[0150] Keep-alive short messages are short messages used to maintain the online or communication-alive status of distributed peripheral modules 134. For example, a keep-alive short message can be a short-format message containing only an online identifier or basic status identifier.

[0151] In some embodiments, the target peripheral module can calculate the local change amount according to the sampling period, and when the absolute value of the relevant difference is less than or equal to the corresponding preset threshold, it will send a short format message containing only the online identifier or basic status identifier after the preset keep-alive period is reached.

[0152] In some embodiments, keep-alive short messages can also be sent in other ways. For example, the target peripheral module can trigger the sending of a single-frame heartbeat message during a bus idle window to maintain online status detection.

[0153] Some embodiments in this specification allocate resource quotas based on predicted power and predicted bandwidth, and perform output degradation and differentiated reporting locally on peripherals, so that critical actions and critical communications are prioritized during overload, reducing invalid load and improving continuous operation capability.

[0154] In some embodiments, the target peripheral module includes a first peripheral module and a second peripheral module. When the resource quota issued by the main control module 131 to the first peripheral module is insufficient, the first peripheral module is configured to initiate a resource borrowing request to the adjacent second peripheral module through the communication bus module 133. The second peripheral module is configured to switch its local execution mode to the minimum resource overhead mode after receiving the resource borrowing request, and transfer the surplus power budget or message transmission budget to the first peripheral module.

[0155] In some embodiments, the target peripheral module includes a first peripheral module and a second peripheral module, wherein the first peripheral module is used to carry out higher priority actions, and the second peripheral module is used to provide lendable resources while meeting its own basic operating requirements.

[0156] The first peripheral module refers to the distributed peripheral module 134 among the target peripheral modules that is a priority resource guarantee object or has a high execution priority.

[0157] The second peripheral module refers to the distributed peripheral module 134 in the target peripheral module that is physically adjacent to or logically related to the first peripheral module and whose current execution action has a relatively low priority.

[0158] In some embodiments, the main control module 131, based on a pre-established topology dictionary and action priority table, marks distributed peripheral modules 134 corresponding to high-priority actions as first peripheral modules, and establishes distributed peripheral modules 134 with first-order or second-order adjacency relationships to the first peripheral modules and with relatively lower current action priorities as second peripheral modules. For example, if the main control module 131 detects that the action priority corresponding to distributed peripheral module A is the highest, then distributed peripheral module A can be marked as the first peripheral module. If distributed peripheral modules B and C have first-order and second-order adjacency relationships with distributed peripheral module A, respectively, and their corresponding action priorities are lower than those of distributed peripheral module A, then distributed peripheral modules B and C can be established as second peripheral modules.

[0159] In some embodiments, when the resource quota issued by the main control module 131 is insufficient, the first peripheral module initiates a resource borrowing request to the adjacent second peripheral module through the communication bus module 133.

[0160] The adjacent second peripheral module refers to the second peripheral module that is physically adjacent to the first peripheral module in terms of spatial location and network topology.

[0161] A resource borrowing request is a request sent by one peripheral module to another to request the transfer of its surplus resource budget. For example, a resource borrowing request may involve power resources or message transmission resources.

[0162] In some embodiments, when issuing resource quotas, the main control module 131 simultaneously determines the priority of the command corresponding to the first peripheral module and the lower limit of the action resource. When the allocated current or message transmission quota is lower than the lower limit required for the current action, the main control module 131 sets a borrowing enable flag in the issued message. After receiving the flag, the first peripheral module queries the locally stored adjacency module table to obtain the hardware addressing address of the adjacent second peripheral module, and sends a point-to-point resource borrowing request to the hardware addressing address through the communication bus module 133.

[0163] The adjacency module table refers to an array of data structures stored in the local memory of the distributed peripheral module 134, used to record the physical communication links and logical topology connections between this module and other distributed peripheral modules 134. The adjacency module table lists in detail the specific module identifiers and hardware addressing addresses of other distributed peripheral modules 134 that are on the same power supply branch or the same local bus segment as the current module and have first-order or second-order adjacency relationships.

[0164] The adjacency module table is obtained as follows: During the robot system's power-on initialization phase, the main control module 131 constructs a global network topology dictionary based on the node polling registration results of the communication bus module 133 and the overall physical structure characteristics of the robot. Subsequently, the main control module 131 extracts local adjacency network mapping fragments for each specific peripheral node from this global network topology dictionary and sends these fragments to the corresponding distributed peripheral module 134 via communication messages. Upon receiving the mapping fragment, the slave microcontroller 1341 of the distributed peripheral module 134 parses it into a structured relation list and permanently or dynamically stores it in local flash memory or RAM.

[0165] In some embodiments, resource borrowing requests can also be initiated in other ways. For example, a first peripheral module may unicast a message to a neighboring second peripheral module in sequence, based on a preset threshold and an adjacency priority lookup table result.

[0166] In some embodiments, after receiving a resource borrowing request, the second peripheral module switches its local execution mode to the minimum resource overhead mode and transfers its surplus power budget or message transmission budget to the first peripheral module.

[0167] Local execution mode refers to the operating or control mode adopted by the distributed peripheral module 134 when performing tasks locally. For example, in an intelligent lighting system, when the distributed peripheral module 134 executes locally, it can automatically adjust the brightness of the lights according to a preset light intensity threshold, without relying on the central controller for real-time command issuance.

[0168] The minimum resource overhead mode refers to a local execution mode that runs with low resource consumption while ensuring the basic functions or basic online status of the distributed peripheral module 134.

[0169] The surplus power budget refers to the share of electrical energy available for lending in the second peripheral module after deducting the electrical energy required to maintain basic operation after entering the minimum resource overhead mode.

[0170] The surplus message transmission budget refers to the share of communication frequency or bandwidth available for lending in the second peripheral module after deducting the share of communication frequency or bandwidth necessary to maintain basic operation after entering the minimum resource overhead mode.

[0171] In some embodiments, after receiving a resource borrowing request, the second peripheral module has its current task evaluated by the slave microcontroller 1341, and performs load self-compression processing without interrupting the basic online state. For example, the second peripheral module reduces the backlight brightness by 60%, lengthens the interpolation time base of the motion mapping curve, reduces the refresh rate of the facial animation from 60 frames per second to 10 frames per second, and suspends unnecessary external sensor sampling. The second peripheral module then subtracts the actual power consumption and communication frequency under minimum resource overhead from the original allocated total budget to obtain the available power budget and message transmission budget, and replies with a borrowing confirmation message through the communication bus module to give up the available power budget and message transmission budget to the first peripheral module, while simultaneously copying it to the master control module 131 for global resource table synchronization.

[0172] In some embodiments, after receiving the borrowing confirmation message returned by the second peripheral module, the first peripheral module incorporates the borrowed power budget and / or message sending budget into its current dynamic resource quota parameters. Based on the updated dynamic resource quota parameters, the first peripheral module increases the local drive torque limit, output limit, or status reporting quota, and drives the actuator 1342 to complete the corresponding temporary high-load action accordingly. After receiving the copy information of the borrowing confirmation, the main control module 131 can update only the global resource table without changing the bus topology.

[0173] In some embodiments, the minimum resource overhead mode and the transferable budget can also be determined in other ways. For example, the second peripheral module looks up the minimum operating parameters according to the current task type based on a pre-stored minimum operating configuration table, and calculates the transferable budget accordingly.

[0174] Some embodiments in this specification release surplus budget through borrowing requests between adjacent distributed peripheral modules and switching with minimum resource overhead, so that high-priority peripherals can still obtain supplementary resources when quotas are insufficient, thereby reducing real-time recalculation by the main controller and improving the completion rate of sudden high-load actions.

[0175] After the distributed peripheral modules receive organ-level instruction 450, to prevent unexpected physical actions caused by logical errors in the main control module or interference with the transmission link, each distributed peripheral module executes a rigorous multi-verification process before converting the instruction into a local control sequence. This process aims to filter out out-of-bounds parameters and invalid commands through local logic, thereby building the last line of defense for security before physical execution on the distributed node side.

[0176] Figure 5 This is an exemplary schematic diagram illustrating multiple verification according to some embodiments of this specification.

[0177] In some embodiments, such as Figure 5As shown, the slave microcontroller 1341 is further configured to: perform multiple checks on the organ-level instruction 450 before converting it into a local control sequence; the multiple checks include parameter range checks; the parameter range checks include: comparing the action parameter 451 in the organ-level instruction 450 with the locally stored physical constraint boundary 510; when the action parameter 451 exceeds the physical constraint boundary 510, adjusting the action parameter 451 to within the physical constraint boundary 510.

[0178] For more information on slave microcontrollers, organ-level instruction set 450, and local control sequences, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0179] In some embodiments, the slave microcontroller 1341 performs multiple checks based on the received organ-level instruction 450 to obtain an instruction that passes the checks.

[0180] Multiple checks refer to a series of sequential checks performed on organ-level instructions 450. For example, multiple checks may include attribution confirmation, function code validity verification, and parameter range verification.

[0181] Parameter range verification refers to the verification process that checks whether the action parameters 451 carried in the organ-level instruction 450 fall within the local allowed range. Parameter range verification occurs after the function code validity verification passes and is the last line of defense of the underlying algorithm to ensure that the mechanical structure does not suffer mechanical damage or overload damage and that the actuator motor does not stall and burn out.

[0182] Attribution confirmation refers to the verification process of determining whether the target module identifier in the received organ-level instruction 450 points to the module itself. For example, the slave microcontroller 1341 uses a serial state machine to process and extract the target module identifier from the received message. If the module identifier stored in the local configuration area matches the target module identifier in the message, the attribution confirmation is successful; if they do not match, the message is immediately discarded in memory to avoid generating any low-level control waveforms and erroneous responses.

[0183] Function code validity verification refers to the logical verification process of checking whether the type of the received action command belongs to the type in the locally supported instruction set list. After the attribution is confirmed, the slave microcontroller 1341 compares it with the instruction set list pre-stored in the flash memory. If the input action command type does not exist in the locally supported instruction set list, the slave microcontroller 1341 directly generates an unsupported action status code and reports it to the master control module 131. At the same time, it terminates subsequent instruction parsing to prevent the hardware from being in an unknown operating state.

[0184] In some embodiments, the slave microcontroller 1341 performs multiple checks, including: sequentially performing attribution confirmation, function code validity verification, and parameter range verification using a serial state machine. During the attribution confirmation phase, the slave microcontroller 1341 extracts the target module identifier from the organ-level instruction 450 and compares it with the module identifier of its own module; if a match is found, it proceeds to function code validity verification; otherwise, it discards the organ-level instruction 450 from memory. During the function code validity verification phase, the slave microcontroller 1341 extracts the action command type and compares it with a pre-stored instruction set list in flash memory; if the input action command type does not exist in the locally supported instruction set list, it indicates that the master control module 131 sent an instruction that this peripheral cannot execute. In this case, the slave microcontroller 1341 directly generates an unsupported action status code and reports it upwards, while simultaneously terminating the subsequent instruction parsing process.

[0185] In some embodiments, the slave microcontroller 1341 can also perform multiple verifications in various ways. For example, attribution confirmation can be completed first in the receive interrupt process, and function code validity verification and parameter range verification can be completed in the parsing task process. The slave microcontroller 1341 uses the result of the previous verification as the trigger condition for the next verification, and only proceeds to the next verification if the previous verification passes.

[0186] In some embodiments, the slave microcontroller 1341 performs a parameter range check based on the action parameter 451 in the organ-level instruction 450 and the locally stored physical constraint boundary 510 to determine whether the action parameter 451 exceeds the physical constraint boundary 510.

[0187] Action parameter 451 refers to parameter values ​​used to characterize or control the action characteristics of an actuator. For example, action parameter 451 can quantitatively guide specific target values ​​for the amplitude, speed, or degree of actuator action. For example, action parameter 451 can be a specific angle value that the servo motor needs to rotate (such as a target rotation of 120 degrees), the target speed of the motor, the speed level of the robotic arm swing, or the target brightness percentage set on the display screen, etc.

[0188] Physical constraint boundary 510 refers to the upper and lower limit range of parameters preset according to the mechanical limits, electrical limits, or safety limits of actuator 1342. For example, physical constraint boundary 510 may include the angular range boundary of the linkage mechanism that can be rotated (such as -90 degrees to +90 degrees), the speed limit range of motor operation (such as a value of 0 to 255), the critical safe operating current that the motor coil can withstand (such as 5 amps), or the screen brightness limit range that a display screen can be set (such as a value of 0 to 100).

[0189] In some embodiments, the slave microcontroller 1341 performs parameter range verification by: extracting action parameters 451 from organ-level instructions 450, and comparing action parameters 451 with the upper and lower limits of the corresponding physical constraint boundaries 510 in the physical constraint boundary table to determine whether action parameters 451 exceed the limits. The physical constraint boundary table can be stored as a static structure in flash memory, and the table entries include safety upper and lower limit feature words for each input parameter (e.g., angle, speed, current, temperature, or brightness).

[0190] In some embodiments, the physical constraint boundary table can also be constructed during the mechanical and electrical design verification phase. For example, critical values ​​such as the critical current at which a motor coil burns out or the mechanical limit angle at which a connecting rod breaks can be accurately determined through finite element analysis thermal resistance simulation and destructive limit overload testing. A specific percentage (e.g., 70%) of these critical values ​​can then be taken as the final safety boundary and written into flash memory.

[0191] In some embodiments, the slave microcontroller 1341 can also perform parameter range verification in various ways. For example, it can compare different boundary items corresponding to different function codes. For instance, the angle control command corresponds to the angle interval boundary, the speed control command corresponds to the speed limit interval, and the brightness control command corresponds to the brightness percentage interval. The slave microcontroller 1341 selects the corresponding boundary item according to the function code and then completes the comparison.

[0192] In some embodiments, whether the action parameter 451 exceeds the physical constraint boundary 510 can also be determined in other ways. For example, the slave microcontroller 1341 performs a size comparison directly based on the thresholds in the preset upper and lower limit registers, without using a boundary table lookup.

[0193] In some embodiments, when the action parameter 451 exceeds the physical constraint boundary 510, the slave microcontroller 1341 performs parameter adjustment to obtain the action parameter 451 located within the physical constraint boundary 510.

[0194] In some embodiments, the slave microcontroller 1341 can also adjust the action parameter 451 in various ways. For example, when the action parameter 451 is greater than the upper limit value, the action parameter 451 is corrected to the upper limit value; when the action parameter 451 is less than the lower limit value, the action parameter 451 is corrected to the lower limit value. The slave microcontroller 1341 writes the adjusted action parameter 451 into the subsequent action execution input buffer for use by the local control sequence generation program.

[0195] For example, once the slave microcontroller 1341 detects that the action parameter 451 (e.g., the input angle is 120 degrees) exceeds the maximum safe limit value allowed in the physical constraint boundary table (e.g., the maximum safe angle limit value is 90 degrees), the slave microcontroller 1341 can directly force the action parameter 451 to be corrected to the corresponding maximum or minimum boundary value (e.g., truncation adjustment to 90 degrees).

[0196] In some embodiments, the slave microcontroller 1341 may further include adjusting the action parameter 451 by replacing the out-of-bounds parameter with the closest valid code value within the physical constraint boundary 510 for graded parameters or code value parameters, and then writing it into the subsequent action execution input buffer.

[0197] In some embodiments, the action parameter 451 can also be adjusted to fit within the physical constraint boundary 510 in other ways. For example, the slave microcontroller 1341 limits the out-of-bounds components one by one based on saturation control logic before outputting them to the local control sequence generation program.

[0198] Some embodiments in this specification, by performing serial verification of attribution, function code, and parameter range before local conversion, and limiting out-of-bounds parameters to within physical constraint boundaries, can avoid erroneous responses and out-of-bounds drives, thereby improving execution security and determinism.

[0199] In some embodiments, the slave microcontroller 1341 is further configured to: after determining that the organ-level instruction 450 has passed multiple verifications, query the locally stored action mapping table based on the organ-level instruction 450 to determine the corresponding local control sequence; wherein the local control sequence includes at least one of a drive signal or a control parameter for controlling the action state of the actuator 1342.

[0200] In some embodiments, the slave microcontroller 1341 queries the locally stored action mapping table based on organ-level instructions 450 to determine the corresponding local control sequence.

[0201] An action mapping table is a data table used to map the action content in organ-level instructions 450 to corresponding local control sequences. For example, the action mapping table can establish a correspondence between action categories and drive sequences or control parameters. For example, for display screen modules, the action mapping table can map the "happy" instruction to a specific expression material sequence; for servo joint modules, the action mapping table can map the "wave" instruction to a reciprocating swing data curve within a preset angle range.

[0202] In some embodiments, obtaining the motion mapping table may include: during the product development and design phase, motion planning engineers design postures in graphical modeling software, perform virtual dynamic physical simulations, and output trajectory curve point data with optimal stability; or by collecting real physical motion data through motion capture devices, performing mathematical sampling and filtering, extracting critical path interpolation points, and finally generating a read-only array that is stored in the flash memory of the slave microcontroller 1341.

[0203] In some embodiments, after determining that the organ-level instruction 450 has passed multiple checks, the slave microcontroller 1341 extracts the action category from the organ-level instruction 450 as a search key; it accesses the action mapping table in the local flash memory and directly searches for the matching result of the table entry corresponding to the search key. After finding a matching table entry, the slave microcontroller 1341 directly reads the local control sequence corresponding to that table entry. For example, the local control sequence may include a discrete execution code sequence, a trajectory point sequence, or a parameter group.

[0204] In some embodiments, the local control sequence can also be determined in other ways. For example, the slave microcontroller 1341 performs address mapping on a pre-stored lookup table based on the action code in the organ-level instruction 450, and reads the corresponding local control sequence according to the mapped address.

[0205] In some embodiments, the slave microcontroller 1341 outputs drive signals or writes control parameters based on the determined local control sequence to control the operating state of the actuator 1342.

[0206] The operating state of actuator 1342 refers to the physical motion characteristics or hardware operating attributes of actuator 1342. For example, the operating state of actuator 1342 can be the rotation angle, speed and output torque of the motor at a specific moment, or the display light arrangement of the display screen at a certain moment.

[0207] A drive signal is an electrical signal output by the slave microcontroller 1341 and used to directly drive the actuator 1342 or drive circuit. For example, a drive signal may include a PWM signal, an enable signal, or a direction control signal.

[0208] Control parameters refer to quantized parameters used to constrain, configure, or adjust the underlying control process. In some embodiments, control parameters may include the proportional gain, integral gain, derivative gain, control output gain, and friction compensation coefficient in a proportional-integral-derivative (PID) control algorithm. These control parameters are all configured variables of the slave microcontroller 1341 during the operation of the underlying control loop. They are read and written to the corresponding control registers by the slave microcontroller 1341 when driving the actuator 1342 to execute official instructions, so as to adjust the response characteristics of the actuator 1342 in real time.

[0209] In some embodiments, when the local control sequence includes a drive signal, the slave microcontroller 1341 directly outputs a pulse level signal according to the timing, pulse width, or level state given by the local control sequence to manipulate the drive bridge or the corresponding drive circuit to work, thereby driving the actuator 1342 to complete the corresponding action.

[0210] In some embodiments, when the local control sequence includes control parameters, the slave microcontroller 1341 writes the target position parameter, target current parameter, or control gain parameter into the underlying controller register, and the underlying control loop performs closed-loop or open-loop control according to the written parameters. In some embodiments, the local control sequence may also include drive signals and control parameters simultaneously, and the slave microcontroller 1341 may write the control parameters first and then output the drive signal.

[0211] In some embodiments, the local control sequence can also be represented in other ways. For example, after the slave microcontroller 1341 reads the pre-stored execution code, it performs the decoding locally and generates drive signals and / or control parameters accordingly.

[0212] Some embodiments in this specification obtain local control sequences by looking up tables locally on the slave microcontroller and directly output drive signals or write control parameters, thereby shortening the link from organ-level instructions to actuator control, reducing the burden on the master controller and improving the execution adaptability of heterogeneous modules.

[0213] In some embodiments, the distributed peripheral module 134 further includes a current detection unit 1344 and an encoder 1345; the slave microcontroller 1341 is configured to: when driving the actuator 1342 to move, monitor the trajectory deviation rate between the actual movement trajectory of the actuator 1342 and the preset target trajectory through the current detection unit 1344 and the encoder 1345; the preset target trajectory is obtained based on the action mapping table; and after driving the actuator 1342 to move, adjust the control parameters in the action mapping table based on the trajectory deviation rate.

[0214] In some embodiments, the distributed peripheral module 134 corresponding to the slave microcontroller 1341 includes a current detection unit 1344 and an encoder 1345.

[0215] The current detection unit 1344 refers to the sampling unit used to detect the real-time operating current of the actuator 1342 during the execution of its action.

[0216] Encoder 1345 refers to a measuring device used to detect the position, displacement, rotation angle and / or speed information of actuator 1342.

[0217] In some embodiments, the current detection unit 1344 includes a current sampling resistor, a signal conditioning circuit, and an analog-to-digital conversion interface. The slave microcontroller 1341 periodically reads the current sampling values ​​during actuator 1342 operation to obtain real-time current information reflecting load changes and motion resistance changes. The encoder 1345 is mounted on the output shaft or drive end of actuator 1342. The slave microcontroller 1341 obtains the angle, displacement, or rotational speed information of actuator 1342 by reading encoder pulses or absolute position codes.

[0218] In some embodiments, the current detection unit 1344 can also be implemented using a Hall current sensor, and the encoder 1345 can also be implemented using an incremental encoder or an absolute encoder. Correspondingly, the slave microcontroller 1341 can perform synchronous sampling and data reading based on different sensor interfaces.

[0219] In some embodiments, when the slave microcontroller 1341 drives the actuator 1342 to move, it monitors the trajectory deviation rate between the actual movement trajectory of the actuator 1342 and the preset target trajectory through the current detection unit 1344 and the encoder 1345.

[0220] The actual motion trajectory refers to the real motion path formed by the actuator 1342 during actual motion execution, which changes over time. For example, the actual motion trajectory can be a trajectory of angle changing over time or a trajectory of displacement changing over time. For example, when the actuator 1342 is a robotic arm, the actual motion trajectory can be the line connecting the actual spatial geometric coordinates of the robotic arm at each sampling moment during its swing. In some embodiments, the slave microcontroller 1341 reads encoder data at high frequency according to a preset sampling period and caches the angle or displacement values ​​at each sampling moment in the memory to form the actual motion trajectory.

[0221] A preset target trajectory refers to a reference trajectory used to characterize the expected motion path of an action. For example, a preset target trajectory can be the target time-position curve that the distributed peripheral module 134 is expected to achieve when performing the corresponding action under standard, interference-free operating conditions. For example, a preset target trajectory can be the ideal transition curve for a servo motor to smoothly rotate to 90 degrees within 0.5 seconds. The preset target trajectory is obtained by calculating the standard position curve and driving torque curve at a preset time resolution (e.g., one millisecond time resolution) through offline dynamic simulation after the action design is completed, and storing them as a static constant array in the preset target trajectory field of the action mapping table for real-time retrieval.

[0222] In some embodiments, the slave microcontroller 1341 obtains a preset target trajectory based on an action mapping table.

[0223] In some embodiments, the action mapping table pre-stores target trajectory fields corresponding to multiple actions. The slave microcontroller 1341 reads the corresponding time-position curve from the action mapping table as the preset target trajectory based on the action command type, action parameters, action duration, etc. in the received organ-level instructions.

[0224] In some embodiments, the preset target trajectory in the action mapping table can also be obtained through calibration. For example, the slave microcontroller 1341 can call reference trajectory data collected under standard operating conditions, or read target position samples at discrete time points, and reconstruct the continuous preset target trajectory through linear interpolation or spline interpolation.

[0225] The trajectory deviation rate is an indicator used to quantify the degree of deviation between the actual motion trajectory and the preset target trajectory. For example, the trajectory deviation rate can be specifically expressed as a quantified percentage value, used to comprehensively reflect the degree of motion distortion caused by mechanical transmission deviations or component wear.

[0226] In some embodiments, the slave microcontroller 1341 can acquire the real-time operating current output by the current detection unit 1344, and compare the actual position at the same moment with the reference position in the preset target trajectory to obtain the position error. The slave microcontroller 1341 then weights and fuses the position error with the real-time operating current to obtain the weighted error of each sampling point, and accumulates or normalizes the weighted error of the entire action cycle to obtain the trajectory deviation rate. The normalization process can be achieved by summing the weighted errors of all sampling points throughout the entire action cycle and then dividing by the sum of the absolute values ​​of the preset target trajectory values ​​of each sampling point throughout the entire action cycle.

[0227] For example, the slave microcontroller 1341 can obtain the trajectory deviation rate using the following formulas (1) and (2): (1), (2),

[0228] in, Indicates the sequence number of the sampling point; Indicates the current sampling point The positional error is expressed by the formula Calculated; This represents the preset target trajectory value of the current sampling point. This indicates the actual trajectory position value of the current sampling point fed back by encoder 1345; This indicates the real-time operating current collected by the current detection unit 1344 at the current sampling point; This represents the preset current weighting constant, which can be a preset empirical constant calibrated and written into the flash memory before leaving the factory; Indicates the trajectory deviation rate; The total number of sampling points within the entire action cycle can be calculated by dividing the action duration in the organ-level command by the preset sampling cycle.

[0229] In some embodiments, the trajectory deviation rate can also be monitored in other ways. For example, the slave microcontroller 1341 looks up the reference position at each moment based on the motion mapping table, calculates the mean square error of the actual position relative to the reference position, and combines it with the average current of the motion cycle according to a preset weight to synthesize the trajectory deviation rate.

[0230] In some embodiments, after the actuator 1342 has completed its action, the slave microcontroller 1341 adjusts the control parameters in the action mapping table based on the trajectory deviation rate.

[0231] In some embodiments, after the execution cycle of an action is completed, the slave microcontroller 1341 automatically initiates a low-level self-calibration program to compare the trajectory deviation rate with a preset limit. Since the low-level actuator drive uses a proportional-integral-derivative (PID) control algorithm, when the trajectory deviation rate exceeds the preset limit, the slave microcontroller 1341 can call a local adaptive control algorithm (e.g., a gradient descent-based optimization algorithm) to fine-tune at least one of the integral gain, proportional gain, and friction compensation coefficient in the control parameters of the action mapping table. For example, when the trajectory deviation rate is large and the real-time current is high, the slave microcontroller 1341 determines that there is increased motion resistance and increases the integral gain and / or the friction compensation coefficient; when overshoot or vibration occurs during the action, the slave microcontroller 1341 reduces the proportional gain. The adjusted control parameters are written back to the action mapping table for use in the next action cycle. A large trajectory deviation rate can refer to a calculated trajectory deviation rate exceeding a preset deviation threshold. The preset deviation threshold can be preset by a technician and stored in the flash memory of the distributed peripheral module 134.

[0232] Among them, when the trajectory deviation rate When the current is large and the real-time current exceeds the current threshold (i.e., too high), the slave microcontroller 1341 increases the integral gain and friction compensation coefficient to match the trajectory deviation rate. They are positively correlated. For example, the slave microcontroller 1341 can increase the integral gain according to the following formula (3). Increase the friction compensation coefficient according to the following formula (4). : (3), (4), in, and These are the adjusted integral gain and friction compensation coefficient, respectively. and These are preset adjustment constants, which can be preset by technicians and stored in the flash memory of the distributed peripheral module 134.

[0233] When overshoot or vibration occurs, the slave microcontroller 1341 reduces the magnitude of the proportional gain, which can be correlated with the trajectory deviation rate. They are positively correlated. For example, the slave microcontroller 1341 reduces the proportional gain according to the following formula (5). : (5), in, This is the adjusted proportional gain; The preset adjustment constant can be preset by technicians and stored in the flash memory of the distributed peripheral module 134.

[0234] In some embodiments, the control parameters can also be adjusted in other ways. For example, the slave microcontroller 1341 increases or decreases the integral gain, proportional gain, or friction compensation coefficient according to the trajectory deviation rate interval based on a preset segmented threshold rule, and writes the updated values ​​into the action mapping table.

[0235] In some embodiments of this specification, a multi-dimensional trajectory deviation rate monitoring mechanism based on the fusion of spatial position error and physical electromagnetic load is constructed by integrating a current detection unit and an encoder within the distributed peripheral module. This mechanism can not only accurately quantify the degree of underlying motion distortion caused by mechanical transmission wear, component aging, or sudden changes in external load, but also allows the slave microcontroller to directly and autonomously fine-tune various control gain parameters of the drive actuator locally after each motion cycle for closed-loop self-calibration. This improves the consistency of motion execution and the ability to maintain high-precision motion under long-term complex operating conditions of the robot system.

[0236] In some embodiments, the distributed peripheral module 134 further includes an inertial measurement unit 1346; the slave microcontroller 1341 is further configured to: obtain the attitude angle of the distributed peripheral module 134 through the inertial measurement unit 1346; calculate and obtain the gravitational torque component locally in real time based on the attitude angle; and add the gravitational torque component as a feedforward torque compensation amount to the control loop when generating the local control sequence.

[0237] In some embodiments, the slave microcontroller 1341 collects attitude and inertial data through the inertial measurement unit 1346 provided in the distributed peripheral module 134 to support subsequent attitude angle acquisition and gravitational torque component calculation.

[0238] An inertial measurement unit 1346 refers to a measurement unit used to sense the attitude and inertial motion state of a component. For example, an inertial measurement unit 1346 may include an accelerometer and a gyroscope.

[0239] In some embodiments, the inertial measurement unit 1346 can be implemented using an integrated six-axis sensor chip, which integrates a three-axis accelerometer and a three-axis gyroscope in the same chip. The slave microcontroller 1341 reads the measurement data through an SPI interface or an Inter-Integrated Circuit (I2C) interface.

[0240] In some embodiments, the inertial measurement unit 1346 can also be implemented using discrete components, consisting of an independent accelerometer and an independent gyroscope. The slave microcontroller 1341 generates attitude calculation input after time-aligning the outputs of the two types of components.

[0241] In some embodiments, the slave microcontroller 1341 obtains the attitude angle of the distributed peripheral module 134 based on the output of the inertial measurement unit 1346.

[0242] The attitude angle refers to the angle between the current attitude of the distributed peripheral module 134 and the direction of gravity. For example, the attitude angle can be the physical tilt angle of the current rotation axis of the distributed peripheral module 134 relative to the direction perpendicular to the Earth's gravity vector.

[0243] In some embodiments, the slave microcontroller 1341 can acquire the attitude angle in various ways, such as reading the three-axis acceleration data and three-axis angular velocity data output by the inertial measurement unit 1346; performing sensor fusion based on the Kalman filter algorithm; and outputting the current tilt angle θ as the attitude angle. Taking the robotic arm joint module as an example, the slave microcontroller 1341 can also first transform the coordinate system of the inertial measurement unit and the joint coordinate system according to the installation direction, and then output the attitude angle corresponding to the rotation axis.

[0244] For example, when the motion changes slowly, the slave microcontroller can calculate the gravity direction component based on the accelerometer output, and obtain the attitude angle by combining the gyroscope integration result and complementary filtering.

[0245] For example, the slave microcontroller 1341 performs coordinate transformation on the output of the inertial measurement unit 1346 based on a preset installation matrix, and calculates the attitude angle using inverse trigonometric functions.

[0246] In some embodiments, the slave microcontroller 1341 calculates and obtains the gravitational torque component locally in real time based on the attitude angle.

[0247] The gravitational torque component refers to the torque component exerted on the relevant rotating shaft or actuator under the current posture due to the gravity of the distributed peripheral module 134 itself. For example, when the robot module performs an upward lifting action, its own structural gravity will generate a reverse gravitational torque component that opposes the rotation of the motor.

[0248] In some embodiments, after the mechanical structure design of the distributed peripheral module 134 is completed, the equivalent mass of the connecting rod, the equivalent length from the center of gravity to the rotation axis, and the reduction ratio and transmission efficiency parameters of the internal transmission mechanism can be accurately measured and extracted by three-dimensional design software, and these data are written into the flash memory of the slave microcontroller 1341.

[0249] The slave microcontroller 1341 can determine the gravitational torque component based on the equivalent mass of the connecting rod, the equivalent length from the center of gravity to the rotation axis, and the reduction ratio and transmission efficiency parameters of the internal transmission mechanism. For example, the slave microcontroller 1341 can determine the gravitational torque component based on the following dynamic equation (6): (6).

[0250] In the above dynamic equation (6), Represents the gravitational torque component. This represents the combined correction factor for the reduction ratio and transmission efficiency of the transmission mechanism. This represents the equivalent mass of the connecting rod. Represents the gravitational acceleration constant. This represents the equivalent length from the center of gravity to the axis of rotation. This represents the current attitude angle. The comprehensive correction coefficient is included. It can be determined by the reduction ratio of the transmission mechanism. With transmission efficiency Comprehensive calculations show that, for example Reduction ratio The transmission efficiency can be determined based on the gear module and the ratio of the number of teeth. This information can be obtained through experimental measurement or by consulting the technical manuals of the relevant mechanical components.

[0251] In some embodiments, the slave microcontroller 1341 can directly convert the dynamic equation (6) and its associated physical quantities into low-level code, which is permanently stored in local flash memory as static parameters of the physical model.

[0252] During the execution of the underlying actuator's actions, the slave microcontroller 1341 reads the raw motion data output by the internal inertial measurement unit 1346 at high frequency through the SPI interface, and uses the Kalman filter algorithm to fuse and smooth the raw data, thereby calculating the actuator's precise attitude angle at the current moment in real time. After calculating the attitude angle, the slave microcontroller 1341 retrieves the physical model parameters pre-stored in flash memory, and multiplies the equivalent mass of the link, gravitational acceleration, equivalent length from the center of gravity to the rotation axis, the sine of the current attitude angle, and the transmission mechanism efficiency correction coefficient, finally completing the dynamic calculation of the current gravitational torque component locally in real time.

[0253] In some embodiments, the slave microcontroller 1341 can also obtain the gravitational torque components in various ways. For example, a correspondence table between the attitude angle and the gravitational torque components can be pre-established; during runtime, the table can be looked up according to the current attitude angle, and the gravitational torque components can be obtained by piecewise linear interpolation or polynomial interpolation.

[0254] For example, the slave microcontroller 1341 calculates and sums the gravitational torque components of each segment based on their equivalent mass, center of gravity position, and current attitude.

[0255] In some embodiments, when generating a local control sequence, the slave microcontroller 1341 adds the gravitational torque component as a feedforward torque compensation amount to the control loop.

[0256] Feedforward torque compensation refers to the torque compensation amount added in advance to the control loop outside of feedback control to offset the effects of gravity loads or attitude disturbances. Traditional closed-loop feedback control usually only begins to play a regulatory role after the system experiences position or velocity errors, exhibiting a certain lag in responding to attitude changes. Feedforward torque compensation introduces a predictive active control mechanism that does not depend on the actual generation of errors but rather calculates the current gravitational torque component in advance based on the local dynamic physical model and compensates for it.

[0257] A control loop refers to a control circuit used for closed-loop regulation of the actuator 1342. For example, a control loop may include a current control loop, a speed control loop, or a position control loop.

[0258] For example, in the motor current closed-loop circuit that generates the local control sequence, the slave microcontroller 1341 can multiply the calculated gravitational torque component by a preset torque constant, converting it into a specific compensation current feedforward value. Subsequently, the slave microcontroller 1341 directly algebraically adds this compensation current feedforward value to the final current control quantity output by the feedback proportional-integral-derivative controller, using it as the final current loop input value for electromagnetic torque control, thereby achieving active feedforward cancellation of external attitude gravity loads. In addition, to prevent the total torque after superimposed compensation from exceeding the limit, the slave microcontroller 1341 performs a safety limiting operation before finally outputting the local control sequence to drive the actuator 1342: forcibly limiting the algebraically accumulated total torque to within the maximum allowable driving torque limit constrained by the current dynamic resource quota parameters; if it exceeds this limit, it automatically performs truncation processing to protect the hardware.

[0259] In some embodiments, the slave microcontroller 1341 can also incorporate the gravitational torque component as a feedforward torque compensation amount into the control loop in various ways. For example, the slave microcontroller 1341 can first convert the gravitational torque component into an equivalent bias amount in the velocity loop or position loop, and then have the downstream current loop track the bias amount; after the bias amount is superimposed, the slave microcontroller 1341 also performs amplitude limiting processing, and then outputs the local control sequence.

[0260] For example, the slave microcontroller 1341 can directly superimpose the gravitational torque component in the feedforward branch of the control loop according to a preset proportional coefficient, and perform amplitude limiting based on the maximum permissible driving torque after superposition.

[0261] In some embodiments of this specification, by introducing an inertial measurement unit locally into the distributed peripheral module and calculating the gravitational torque component in real time, and directly adding it as a feedforward compensation quantity to the underlying control loop, the effects of nonlinear gravitational disturbances caused by changes in the robot's spatial posture can be effectively offset and reduced. This feedforward compensation mechanism allows the underlying microcontroller to autonomously overcome the bias load caused by changes in structural weight without relying on the complex global dynamics calculations of the main control module. This ensures that the same abstract semantic instructions maintain a high degree of consistency in motion execution speed, motion stability, and spatial trajectory accuracy under different spatial operating postures.

[0262] Throughout the entire execution cycle, to ensure the hardware safety of the distributed robot system and prevent secondary failures caused by extreme conditions such as excessive temperature rise, abnormal current, or over-limit switching of the actuator 1342, each distributed peripheral module 134 not only possesses local instruction verification capabilities but also incorporates a high-frequency parameter monitoring and autonomous protection mechanism. This mechanism enables the distributed peripheral module 134 to directly cut off power output locally within microseconds without waiting for the main control module 131's decision when it detects a physical parameter triggering red line, thereby shortening the safety response path to the execution node itself.

[0263] Figure 6 These are exemplary schematic diagrams illustrating the monitoring of physical parameters according to some embodiments of this specification.

[0264] In some embodiments, such as Figure 6 As shown, the distributed peripheral module 134 also includes a parameter sensor 1347 for continuously monitoring the physical parameter 610; the slave microcontroller 1341 is configured to: acquire the physical parameter 610 of the parameter sensor 1347 at a preset sampling frequency; and in response to the detection of the physical parameter 610 triggering a local safety threshold, directly execute power failure or leakage protection on the local control actuator 1342.

[0265] For more information on the distributed peripheral module, slave microcontroller 1341, and actuator 1342, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0266] Physical parameter 610 refers to a physical quantity parameter that can characterize the operating state, load state, or safety state of actuator 1342. For example, physical parameter 610 may include temperature, operating current, or a level toggling signal generated when the actuator touches a travel limit switch.

[0267] Parameter sensor 1347 refers to a sensor or detection element used for continuous monitoring of physical parameters. For example, parameter sensor 1347 may include a temperature sensor, a current detection device, or a limit detection device.

[0268] In some embodiments, the parameter sensor 1347 includes an onboard precision sampling resistor and a temperature-sensitive thermistor. The precision sampling resistor is arranged in the drive circuit to output a sampling voltage corresponding to the drive current; the thermistor is arranged near the actuator coil, drive bridge, or heating area to output a voltage signal corresponding to the temperature rise.

[0269] In some embodiments, the parameter sensor 1347 may further include a limit detection device. The limit detection device is installed at the extreme position of the actuator and outputs a level-to-level signal when the actuator touches the limit position to continuously reflect whether the actuator has entered the dangerous travel range.

[0270] In some embodiments, the parameter sensor 1347 may also include a Hall current sensor or a temperature control switch, and directly output an analog or switching signal reflecting the overcurrent or overtemperature state.

[0271] In some embodiments, the slave microcontroller 1341 acquires the physical parameters 610 of the parameter sensor 1347 at a preset sampling frequency based on the output of the parameter sensor 1347.

[0272] The preset sampling frequency refers to the sampling frequency that is preset when periodically sampling the parameter sensor 1347. In some embodiments, the preset sampling frequency can be preset and stored in the flash memory of the slave microcontroller 1341.

[0273] In some embodiments, the slave microcontroller 1341 is configured with a hardware timer interrupt. When the timer overflows, the slave microcontroller 1341 automatically triggers a multi-channel analog-to-digital converter to sample the current sampling voltage value and the temperature voltage value, and converts them to obtain the current drive current value and temperature value.

[0274] In some embodiments, the slave microcontroller 1341 can also acquire data from the digital parameter sensor 1347 at a preset sampling frequency. Taking a limit detection device as an example, the slave microcontroller 1341 reads the input state of the general-purpose input / output (GPIO) during a periodic clock interrupt, or latches the level flipping result generated by an external interrupt during the sampling period to obtain the current limit position state.

[0275] In some embodiments, the physical parameter 610 can also be acquired in other ways. For example, the slave microcontroller 1341 performs periodic detection of the current sampling signal based on an analog comparator and reads temperature channel data within the same sampling window to complete local sampling.

[0276] In some embodiments, the slave microcontroller 1341, in response to the detection of physical parameter 610 triggering a local safety protection threshold, directly executes power failure or leakage protection on the local control actuator 1342.

[0277] The local security protection threshold refers to the threshold that is pre-set locally in the distributed peripheral module 134 to determine whether to enter the security protection state.

[0278] Discharge protection refers to the protective action implemented by reducing, clearing or releasing the output torque or holding force of actuator 1342.

[0279] In some embodiments, the slave microcontroller 1341 can compare the acquired physical parameters 610 with local safety protection thresholds to determine whether to trigger local safety protection. The acquisition of the current and temperature thresholds may include: during the mechanical and electrical design verification phase, determining the critical current and temperature limits for motor coil burnout through finite element analysis thermal resistance simulation and destructive overload testing; then taking the safety derating ratio (e.g., 70%) of the critical current and temperature limits as the current and temperature thresholds, and directly storing them in the flash memory of the peripheral slave microcontroller 1341.

[0280] In some embodiments, when the slave microcontroller 1341 detects that the drive current or temperature exceeds the local safety protection threshold, it enters a high-priority emergency protection interrupt and directly controls the GPIO hardware pin to pull down the enable pin of the driver chip to cut off the power bridge supply, thereby causing the actuator 1342 to perform power-off protection. This protection process is completed locally without bus reporting or master control decision-making.

[0281] In some embodiments, when the slave microcontroller 1341 detects that the physical parameter 610 triggers the local safety protection threshold, it can also directly shut down the pulse width modulation output and clear the motor's driving torque to zero or put the control line into a high-resistance state to release the output torque or holding force of the actuator 1342, thereby performing force leakage protection. Taking a brushless motor actuator as an example, in the event of an abnormally high operating current or continuous execution timeout, shutting down the pulse width modulation output can be prioritized to reduce mechanical shock and heat accumulation.

[0282] In some embodiments of this specification, parameter sensors are introduced locally in the distributed peripheral module to continuously monitor physical parameters at high frequency. The slave microcontroller is granted the highest execution authority to directly trigger the underlying power failure or leakage protection without the master control module's decision-making, thus shortening the physical path for the system's safety response. This effectively avoids the problem of delayed protection command issuance caused by communication bus congestion or global computing power preemption by the master control module under complex concurrent operating conditions. It also prevents the risk of underlying hardware burnout under extreme overload or physical jamming conditions, improving the overall operational safety and long-term hardware reliability of the robot system.

[0283] In some embodiments, the distributed peripheral module 134 further includes a bus transceiver 1343; when the slave microcontroller 1341 of the first peripheral module performs local power failure or leakage protection, it broadcasts a high-priority safety interrupt frame to the communication bus module 133 through the bus transceiver 1343; after receiving the safety interrupt frame, the second peripheral module adjacent to the first peripheral module performs at least one of deceleration, coordinated emergency stop or power output limitation locally.

[0284] In some embodiments, the slave microcontroller 1341 in the distributed peripheral module 134 is connected to the communication bus module 133 through the bus transceiver 1343 set in the module to realize bidirectional communication between the local control logic and the bus physical layer.

[0285] Bus transceiver 1343 refers to a hardware interface device used for bidirectional physical level conversion between the logic level of slave microcontroller 1341 and the differential bus signal of communication bus module 133. For example, bus transceiver 1343 can be specifically manifested as a Controller Area Network (CAN) transceiver chip or an RS-485 transceiver chip. In some embodiments, bus transceiver 1343 can convert the single-ended digital signal output by slave microcontroller 1341 into a differential signal with strong anti-interference capability and output it to the communication bus module, while converting the differential bus signal on the communication bus module into a digital level that can be read by the microcontroller, thereby realizing stable network communication at the physical layer.

[0286] In some embodiments, the slave microcontroller 1341 in the distributed peripheral module 134 can be connected to the communication bus module 133 via a CAN transceiver. The CAN transceiver is located between the transmit port, receive port and differential bus of the slave microcontroller 1341, and is used to perform the conversion between single-ended digital signals and CAN_H and CAN_L differential signals.

[0287] In some embodiments, the slave microcontroller 1341 in the distributed peripheral module 134 can also be connected to the communication bus module 133 via an RS-485 transceiver. The RS-485 transceiver can be connected to a half-duplex or full-duplex bus and, in conjunction with a direction control signal, complete the switching between the transmit and receive channels.

[0288] In some embodiments, the slave microcontroller 1341 in the first peripheral module executes a high-priority security interrupt frame broadcast based on a local power failure or leakage protection trigger event, so that adjacent peripheral modules can enter a security response without going through the master controller.

[0289] A security interruption frame is a high-priority message used to quickly broadcast a security event on the communication bus module 133 and trigger the relevant module to immediately execute a protection response. In an embodiment that uses a CAN bus as the communication bus module 133, the security interruption frame can be a bus message with all arbitration identification codes set to zero (such as 0x00). This message can directly preempt the communication bus module 133 without delay using the physical layer bit-by-bit arbitration mechanism.

[0290] In some embodiments, when the slave microcontroller 1341 in the first peripheral module detects that the local power failure protection or leakage protection has been triggered, it can synchronously trigger the internal hardware controller to send a security interrupt frame. The message identifier of the security interrupt frame is set to a fixed value with the highest bus physical priority, enabling the frame to directly preempt the bus and complete the broadcast through a bit-arbitration mechanism.

[0291] In some embodiments, the slave microcontroller 1341 in the first peripheral module can also write a preset emergency identifier into the transmit mailbox after a local protection interruption occurs, and immediately send a safety interruption frame through the bus transceiver 1343. The payload of the safety interruption frame may include at least one of fault type, node identifier, or protection level, so that adjacent peripheral modules can locally select a response method.

[0292] In some embodiments, the security interrupt frame can also be broadcast in other ways. For example, the slave microcontroller 1341 in the first peripheral module selects the highest priority message identifier according to a preset arbitration priority table and directly triggers emergency transmission based on bus control logic.

[0293] In some embodiments, the slave microcontroller 1341 in the second peripheral module performs at least one of deceleration, coordinated emergency stop, or power output limitation locally based on a security interrupt frame received by the bus transceiver 1343.

[0294] Collaborative emergency stop refers to the emergency stop action that the relevant distributed peripheral module 134 performs synchronously to avoid linkage risks after receiving security event information (such as the aforementioned security interruption frame).

[0295] Power output limiting refers to protective measures that restrict the drive output capability of an actuator. For example, power output limiting can be achieved by reducing the maximum current limit or reducing the maximum torque limit.

[0296] In some embodiments, the slave microcontroller 1341 in the second peripheral module can capture a safety interrupt frame in the physical layer receive interrupt via a hardware receive filter and read the locally stored cooperative linkage table. When the cooperative linkage table indicates that the first peripheral module and the second peripheral module are on the same robotic arm or there is a risk of interference or collision, the slave microcontroller 1341 can reset the target speed to zero and disable the power output enable to perform a cooperative emergency stop; or quickly reduce the maximum current limit or maximum torque limit of the driver to perform power output limitation.

[0297] In some embodiments of this specification, a low-level direct communication mechanism based on high-priority safety interrupt frames is established between distributed peripheral modules. This enables other adjacent peripheral modules in the network topology that are at risk of motion interference to be instantly notified via broadcast when a node module experiences a physical failure or triggers a local emergency shutdown. This decentralized edge-linked avoidance strategy allows adjacent modules to directly trigger and execute local anti-collision responses within a microsecond timescale without waiting for global scheduling intervention or command forwarding from the main control module. This reduces the risk of secondary interference and physical collision damage to the robot's complex mechanical structure under abnormal operating conditions.

[0298] In some embodiments, the distributed peripheral module 134 further includes an angle encoder 1348, which is configured to acquire angle data in real time; the slave microcontroller 1341 is configured to acquire the spatial occupancy parameters of the distributed peripheral module 134 based on the angle data, and periodically broadcast them to the communication bus module 133; the second peripheral module is configured to receive the spatial occupancy parameters broadcast by the adjacent first peripheral module, and then use a collision detection algorithm locally to calculate the minimum spatial distance between itself and the adjacent first peripheral module in real time; in response to the minimum spatial distance being less than a safety warning value, the current action execution speed is reduced.

[0299] An angle encoder 1348 refers to an encoder installed on an external joint shaft or related rotating part to obtain current rotation angle information. For example, the angle encoder 1348 can be an absolute multi-turn photoelectric encoder or a high-precision magnetic encoder.

[0300] Angle data refers to numerical data output by the angle encoder 1348 that characterizes the current rotation angle or attitude angle of a component. For example, angle data can be a digital signal reading indicating that the robotic arm is currently raised to a height of forty-five degrees.

[0301] In some embodiments, the distributed peripheral module 134 performs periodic sampling through an absolute multi-turn encoder on the joint axis, and the interface circuit within the module reads the absolute angle value in the encoder register via the SPI interface to obtain real-time angle data.

[0302] In some embodiments, the distributed peripheral module 134 may also use the serial angle value or pulse width angle value output by the high-precision magnetic encoder, and obtain real-time angle data after local decoding and zero-position correction.

[0303] In some embodiments, the distributed peripheral module 134 obtains the spatial occupancy parameters of the distributed peripheral module 134 based on angle data, and periodically broadcasts them to the communication bus module 133.

[0304] Spatial occupancy parameters refer to a set of data parameters used to quantitatively characterize the spatial boundary range occupied or swept by the distributed peripheral module 134 in its current posture. For example, spatial occupancy parameters may include oriented bounding box parameters or their vertex coordinate data. Among them, the oriented bounding box parameters can be the length, height, width, and spatial three-dimensional coordinate values ​​of the eight vertices of the oriented bounding box (OBB) that most tightly wraps the three-dimensional solid model of the peripheral and whose orientation axis rotates with the rotation of the peripheral.

[0305] In some embodiments, after the mechanical structure design is completed, the geometric envelope parameters (i.e., length, width, and height) of the cuboid surrounding the peripheral link entity can be calculated by exporting the robot's link geometric parameter model, and these parameters are then stored as static parameters in the flash memory of the slave microcontroller 1341. During real-time operation, the distributed peripheral module 134 obtains the three-dimensional spatial coordinates of the eight vertices of the orientation bounding box under the current posture based on the angle data acquired in real time and using the built-in robot kinematics forward solution model. The eight vertices coordinates are then converted into relative difference values ​​relative to the reference point coordinates carried in the same broadcast data packet, encapsulated into a broadcast data packet, and broadcast to the communication bus module 133 at a preset period.

[0306] In some embodiments, the spatial occupancy parameters can also be obtained in other ways. For example, the distributed peripheral module 134 can directly retrieve the corresponding spatial occupancy parameters from the current angle data based on a pre-established angle interval and spatial boundary parameter lookup table and broadcast them.

[0307] In some embodiments, after receiving the spatial occupancy parameters broadcast by the adjacent first peripheral module, the second peripheral module uses a collision detection algorithm locally to calculate the minimum spatial distance between itself and the adjacent first peripheral module in real time.

[0308] Collision detection algorithm refers to a calculation method used to determine whether the geometric boundaries of two distributed peripheral modules 134 in space are close, intersecting, or have a risk of collision.

[0309] Minimum spatial distance refers to the shortest geometric distance between the corresponding spatial boundaries of two distributed peripheral modules 134.

[0310] In some embodiments, after receiving the bounding box vertices coordinates broadcast by the first peripheral module, the second peripheral module generates the oriented bounding box of the first peripheral module locally, and combines it with its own real-time bounding box to call the split axis theorem collision detection algorithm to perform projection overlap analysis on multiple projection axes and calculate the minimum spatial distance between the two bounding boxes.

[0311] In some embodiments, after the second peripheral module receives the orientation bounding box parameter group broadcast by the first peripheral module, its internal slave microcontroller 1341 can locally call the built-in collision detection algorithm (such as the split axis theorem collision detection algorithm) to perform projection overlap analysis on multiple projection axes on the orientation bounding box coordinates of the first peripheral module and its own real-time orientation bounding box coordinates, and then calculate the minimum straight-line spatial distance between the two bounding boxes in the current three-dimensional space in real time, which is used as the minimum spatial distance.

[0312] In some embodiments, the second peripheral module reduces the current action execution speed in response to the minimum spatial distance being less than a safety warning value.

[0313] The safety warning value refers to a preset critical distance value used to determine whether there is a risk of physical interference between the distributed peripheral modules 134. For example, the safety warning value can be set as a safety anti-collision buffer margin of five centimeters. The safety warning value is obtained by calculating the lower limit of the safe stopping distance during the robot's factory safety calibration stage after comprehensively evaluating the motion inertia, maximum running speed and underlying braking response time of the peripheral modules, and then directly storing it as a constant in the flash memory of the slave microcontroller 1341.

[0314] Motion execution speed refers to the speed at which an actuator performs the current action. For example, motion execution speed can be the angular velocity of a joint or the rate of change of displacement. For example, motion execution speed can be the angular velocity of a motor's rotation or the linear velocity of a robotic arm's swing.

[0315] In some embodiments, after detecting that the minimum spatial distance is less than the safety warning value, the second peripheral module directly adjusts the interpolation operation parameters locally, lengthens the running time step or timer comparison step of the current action, so that the motion speed curve decreases smoothly, thereby achieving non-emergency stop collision avoidance deceleration.

[0316] In some embodiments, the second peripheral module can also apply a scaling factor to the current speed command according to the ratio between the minimum spatial distance and the safety warning value. The closer the minimum spatial distance is to zero, the smaller the speed scaling factor, thereby gradually reducing the action execution speed.

[0317] In some embodiments, reducing the speed of action execution can also be achieved in other ways. For example, the second peripheral module maps the minimum spatial distance to multiple speed levels according to preset segmented control logic, and switches to the corresponding lower speed when the distance enters different speed ranges.

[0318] In some embodiments of this specification, by having each distributed peripheral module periodically broadcast its own spatial occupancy parameters to the communication bus, and by having adjacent modules autonomously calculate the minimum spatial distance in real time using collision detection algorithms locally, a smooth deceleration and avoidance response at the underlying level can be triggered before actual mechanical physical interference occurs. This decentralized active collision avoidance control mechanism based on edge computing power not only eliminates the high centralized computing power burden on the main control module in complex three-dimensional geometric overlap calculations, but also eliminates the problem of delayed obstacle avoidance actions caused by bus communication delays, thereby improving the physical safety boundaries and motion smoothness of the robot system in scenarios of dense collaborative motion of multiple peripherals.

[0319] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0320] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0321] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0322] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0323] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0324] For each patent, patent application, patent application publication, and other material such as articles, books, specifications, publications, and documents referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0325] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A control system for distributed robot peripherals, characterized in that, The system includes: The main control module is configured as follows: Generate abstract semantic instructions based on business task data; Based on the peripheral module information reported by the distributed peripheral module and the abstract semantic instructions, multiple organ-level instructions are generated; the peripheral module information includes at least status information. The differential host module is configured to convert the digital communication data output by the host module into differential bus signals; The communication bus module is configured to transmit the organ-level instructions and the peripheral module information; Multiple distributed peripheral modules, each including a slave microcontroller and one or more actuators, are configured as follows: The peripheral module information is reported to the main control module; The slave microcontroller is configured as follows: Receive organ-level instructions transmitted via the communication bus module; The organ-level instructions are converted into local control sequences, and the actuators are driven to perform corresponding actions based on the local control sequences. During and / or after the execution of an action, the status information is fed back to the main control module.

2. The system according to claim 1, characterized in that, The peripheral module information also includes the power consumption timing feature spectrum and bandwidth occupancy feature spectrum corresponding to the actions of the distributed peripheral module; The main control module is also configured to: Based on the power consumption timing feature spectrum and the bandwidth occupancy feature spectrum, the power prediction value and bandwidth prediction value of the multiple organ-level instructions at each time step are determined. Based on the bandwidth prediction value and the power prediction value, determine whether there is an overload risk at each time point; In response to the risk of overload at a certain moment, the abstract semantic instructions are rearranged until the risk of overload no longer exists at that moment.

3. The system according to claim 1, characterized in that, The slave microcontroller is further configured to: Before the organ-level instructions are converted into local control sequences, multiple checks are performed on the organ-level instructions, including parameter range checks. The parameter range verification includes: The action parameters in the organ-level instructions are compared with the locally stored physical constraint boundaries; When the action parameter exceeds the physical constraint boundary, the action parameter is adjusted to be within the physical constraint boundary.

4. The system according to claim 3, characterized in that, The slave microcontroller is also configured to: After determining that the organ-level instruction has passed the multiple verifications, the corresponding local control sequence is determined by querying the locally stored action mapping table based on the organ-level instruction. The local control sequence includes at least one of a drive signal or a control parameter for controlling the actuator's operating state.

5. The system according to claim 4, characterized in that, The distributed peripheral module also includes parameter sensors for continuous monitoring of physical parameters; The slave microcontroller is configured as follows: The physical parameters of the parameter sensor are collected at a preset sampling frequency; In response to the detection of the physical parameters triggering the local safety protection threshold, the actuator is directly controlled locally to perform power outage or leakage protection.

6. A control method for distributed robot peripherals, characterized in that, The method includes: The system receives organ-level instructions from the main control module; wherein the organ-level instructions are generated by the main control module based on peripheral module information and abstract semantic instructions, and the abstract semantic instructions are generated based on business task data; the peripheral module information includes status information. The organ-level instructions are converted into local control sequences, and the actuators are driven to perform corresponding actions based on the local control sequences. During and / or after the execution of an action, the status information is fed back to the main control module.

7. The method according to claim 6, characterized in that, The peripheral module information also includes power consumption timing feature spectrum and bandwidth occupancy feature spectrum; The abstract semantic instruction is related to the bandwidth prediction and power prediction values ​​of the organ-level instruction at each time step; The predicted bandwidth and power values ​​of the organ-level instructions at each time step are determined based on the power consumption timing feature spectrum and the bandwidth occupancy feature spectrum.

8. The method according to claim 6, characterized in that, The method further includes: Before the organ-level instructions are converted into local control sequences, multiple checks are performed on the organ-level instructions, including at least parameter range checks. The parameter range verification includes: The action parameters in the organ-level instructions are compared with the locally stored physical constraint boundaries; When the action parameter exceeds the physical constraint boundary, the action parameter is adjusted to be within the physical constraint boundary.

9. The method according to claim 8, characterized in that, The method further includes: After determining that the organ-level instruction has passed the multiple verifications, the corresponding local control sequence is determined by querying the locally stored action mapping table based on the organ-level instruction. The local control sequence includes at least one of a drive signal or a control parameter for controlling the actuator's operating state.

10. The method according to claim 9, characterized in that, The method further includes: Physical parameters are collected at a preset sampling frequency; In response to the detection of the physical parameters triggering the local safety protection threshold, the actuator is directly controlled locally to perform power outage or leakage protection.

Images