Robot based on embedded domain control

Abstract

The invention discloses a robot based on embedded domain control. The robot comprises an embedded domain control module, a power source, a power source management module and an executing mechanism which are arranged on a robot body. The actuating mechanism comprises a joint motor, a sensor, a servo motor and a brake mechanism; a four-layer framework of a task layer, a driving layer, a hardware layer and a mathematical function library is deployed in the embedded domain control module, and function modularization with tasks as units is achieved. When hardware is replaced, only hardware layer drive codes need to be modified; meanwhile, a single-function module can be independently debugged through modular development; the operation safety is comprehensively enhanced, the risks of starting faults, out-of-control of the motor and load falling are avoided, the zero falling risk is achieved, and the requirements of families, medical treatment and other scenes with extremely high safety requirements can be met.

Description

Technical Field

[0001] This invention belongs to the field of robotics technology and relates to a robot based on embedded domain control. Background Technology

[0002] With the rapid development of service robots, industrial collaborative robots, and home companion robots, semi-humanoid robots, due to their human-like movement capabilities, multimodal interaction capabilities, and scene adaptability, have become an important direction for the development of robotics technology. The core performance of a semi-humanoid robot depends entirely on its embedded hardware and software system, which is the physical foundation and core of the robot's function execution. Its role runs through the entire process of robot power supply, environmental perception, and command execution, directly determining whether the robot can achieve its preset functions, its operational reliability, and its practicality.

[0003] However, the embedded hardware and software systems of current semi-humanoid robots still face the following pressing technical challenges: (1) The current embedded robots do not have a fault self-diagnosis and fault tolerance mechanism. If a bug occurs in the software (such as abnormal motor control commands), it may cause the robot to malfunction, threatening the safety of personnel or the environment.

[0004] For humanoid robots, their motors may malfunction due to external environmental factors. For example, when the load is too large, the actuator may overheat or even overload. In this case, the motor may stop outputting torque due to the malfunction, which may cause the robot to move incorrectly and cause harm.

[0005] (2) The software and hardware are relatively independent, and there is a lack of software and hardware collaboration in handling complex robot systems. The core advantage of semi-humanoid robots lies in human-like movements and interactions; if the system cannot achieve software and hardware collaboration in data processing, energy efficiency management, etc., it will affect the robot's performance and may even lead to safety issues.

[0006] In addition, humanoid robot systems have a high degree of freedom and use a large number of motors. If they are started at the same time, the instantaneous current generated may exceed the bearing capacity of the motor drive board, thereby damaging the motors. Summary of the Invention

[0007] The present invention addresses the problem of providing an embedded semi-humanoid robot that enables the robot to operate normally and cope with abnormal situations through hardware and software collaboration.

[0008] This invention is achieved through the following technical solution: An embedded domain controller-based robot includes an embedded domain controller module, a power supply, a power management module, and an actuator mounted on the robot's torso; the actuator includes joint motors, sensors, servo motors, and a braking mechanism. The embedded domain controller module has a four-layer architecture of task layer, driver layer, hardware layer and mathematical function library, which realizes functional modularization based on task. The task layer is the top layer, which contains task files for deploying functional modules. A task file in the task layer contains the implementation logic or control program for a specified task based on the interface provided by the driver layer. The driver layer is an intermediate layer that encapsulates program packages that implement the various processes of the task module and provides a standardized function interface for calling according to task logic to the task layer or the same driver layer. The hardware layer is the bottom layer, which encapsulates the initialization and startup programs of peripherals with actuators, and provides standardized function interfaces for calling peripherals to the driver layer or task layer. The mathematical function library is a support layer that encapsulates the mathematical functions required to implement the specific functions in the functional modules and provides standardized function interfaces to the driver layer. When executing a task, the task layer calls the task module function interface of the driver layer and the peripheral function interface of the hardware layer according to the task logic, driving the corresponding peripheral device in the execution mechanism to execute the task.

[0009] Furthermore, the embedded domain controller module also deploys a hardware-software co-operation program, which builds peripherals suitable for different hardware at the hardware layer, integrates a co-operation control function interface at the driver layer, and deploys hardware-software co-operation control logic at the task layer. The embedded domain control module integrates a multi-channel GPIO interface, a CAN bus interface, an RS485 bus interface, a USART communication interface, an AD sampling interface, and a PWM output interface, and provides real-time data acquisition and command output channels.

[0010] Furthermore, the power management module includes a soft-start module connected to the power supply via an air switch and a DC contactor. The soft-start module receives a PWM signal sent by the embedded domain control module to adjust the starting current slope. The embedded domain control module controls the on / off of the total power supply to the upper body of the robot via the DC contactor. The soft-start module includes a current control section and a power detection section; The current control section includes a MOSFET and a PWM wave input circuit. The source of the MOSFET is connected to the negative terminal of the power supply, and the drain is connected to the negative terminal of the robot load. The PWM wave input circuit includes a filter that performs RC filtering on the PWM signal output by the embedded domain control module, which is then amplified and input to the gate of the MOSFET to achieve gradual turn-on of the MOSFET. The power detection section includes a sampling resistor connected in series to the negative terminal of the power supply's output circuit, and a voltage divider circuit connected in parallel with the sampling resistor; the ADC of the embedded domain control module measures the voltage of the voltage divider circuit to obtain the current value of the power supply circuit. Current control and power supply circuit current sampling are both handled by the embedded domain control module.

[0011] Furthermore, the control program for adjusting the startup current slope of the soft-start module is deployed at the task layer, and its control logic is as follows: a. Startup phase: A high-level output is made through GPIO to close the DC contactor; then a PWM signal is output to the soft-start module and the initial duty cycle is set; b. Real-time adjustment: Read the current sampling value in real time. If the current is less than 1.2 times the rated current, increase the PWM duty cycle at the set rate. If the current is greater than or equal to 1.2 times the rated value, pause the increase and maintain the current duty cycle until the current drops. c. Startup complete: The soft start ends when the duty cycle reaches 100% and the current stabilizes.

[0012] Furthermore, the joint motor uses a collimated drive driver and communicates with the embedded domain control module via a CAN bus. The embedded domain control module monitors the joint motor signals in real time, including the motor's position, speed, current, and fault codes. These signals are received at the hardware layer and the following monitoring is performed at the task layer: When the current value of the joint motor approaches the threshold, a load reduction command is sent to limit the output torque of the joint motor to less than or equal to the rated torque, and continuous monitoring is performed; when the current value of the joint motor is less than the rated current, normal operation is restored; and a communication timeout threshold is set for the joint motor, and if the joint motor does not receive a command within a certain period of time, it enters a disabled state.

[0013] Furthermore, the task layer also includes a signal loss detection task. This task counts each signal, incrementing the counter by one every cycle, and resetting the counter for that signal at the signal receiver in the hardware layer. When the counter value is greater than the threshold, the signal is considered to have been lost. When it is determined that a joint motor signal has been lost, the abnormal state of the joint motor is determined and classified by tracing back the fault code in the last frame of the motor data packet: If no fault code is found, the CAN bus signal is lost; the embedded domain controller module attempts to re-establish communication by restarting the communication and reports the situation. If the fault is determined to be an over-temperature fault, a safety stop command is triggered, and the joint motor is controlled to enter a low torque mode; once the motor temperature returns to the normal range, the fault is cleared and the torque output of the joint motor is restored; If the fault is determined to be an overload fault, the joint motor should be stopped immediately. Once the joint motor returns to normal, the fault should be cleared and the operation resumed. When an unremovable fault occurs in the joint motor, a joint motor stop command is sent, and the motor status is recorded.

[0014] Furthermore, each servo motor is equipped with an individual servo driver, which is connected to the embedded domain control module via a motor communication interface and an RS485 bus. The braking mechanism includes an electromagnetic brake mounted on a servo driver and a brake relay connected to an embedded domain control module; the control terminal of the brake relay is connected to the output of an optocoupler isolation board, and the input of the optocoupler isolation board is connected to the GPIO interface of the embedded domain control module; the embedded domain control module controls the electromagnetic brake by switching the brake relay on and off.

[0015] Furthermore, the task layer includes a braking control task to perform servo motor braking linkage control to prevent the load from falling; its linkage control logic is as follows: a. Status judgment: The braking control task reads the status signal of the servo motor controller in real time. When the servo motor controller enters a disabled state due to a fault, the embedded domain control module controls the servo motor to stop torque output through the hardware layer. b. Braking control: When the servo motor controller is detected to be in a disabled state and the output torque of the servo motor is less than the working torque, a high level is immediately output through the hardware layer relay drive to control the brake relay to engage, and the electromagnetic brake is de-energized and locked. When the servo motor controller is detected to have cleared the fault and entered the enabled state, and the servo motor output torque is the working torque, the brake relay is released by outputting a low level through the hardware layer relay, and the servo motor is allowed to move after a certain delay.

[0016] Furthermore, the task layer also includes a task_los task, which sets different monitoring times of 50~200ms for different signals, including monitoring of motor status, sensor data status, and domain control communication status; and generates a signal health code for each signal, where 0 represents normal and 1 represents abnormal. Data upload: Combine and package the health codes of all signals, and send them to the industrial control computer via USB serial port; Industrial PC Response: After receiving abnormal information in the health code signal, the industrial PC will remind the user of the abnormal part through the human-machine interface, and at the same time send a restriction action command to the embedded domain control module to control the robot to enter a safe posture.

[0017] Compared with the prior art, the present invention has the following beneficial effects: (1) The portability and maintenance efficiency of the embedded domain controller module are greatly optimized, shortening the R&D cycle. Existing embedded system software is mostly based on customized development using general-purpose operating systems, with strong coupling between code and hardware (such as sensor data parsing logic being directly written into the application layer). Replacing the main control chip (such as upgrading from STM32F1 to F4) requires refactoring more than 50% of the code, resulting in low development efficiency. In contrast, this invention adopts a four-layer framework of task layer, driver layer, hardware layer, and mathematical function library. When replacing hardware, only the hardware layer driver code needs to be modified (the amount of modification is less than 10%), shortening the software porting cycle from one month to less than one week. At the same time, modular development allows single-function modules (such as power soft start and brake linkage) to be debugged independently, reducing fault location time from 24 hours to 2 hours, reducing software maintenance costs by 60%, and significantly improving R&D efficiency.

[0018] (2) Operational safety has been comprehensively enhanced to avoid the risks of start-up failure, motor runaway, and load drop. The existing system has three major safety hazards: the initial starting current exceeds the component's carrying capacity (easily burning out the power module), there is no protection measure after the motor signal is lost (easily causing collisions), and the load falls when the servo motor fails (threatening personnel safety); this invention overcomes the above defects through targeted design: a. Power supply soft start control: By adjusting the MOSFET and monitoring the current in real time, the initial start current (inrush current) is controlled within 1.5 times the rated current, avoiding damage to the power module and motor drive circuit due to overcurrent, and extending the life of components by more than 2 times; b. Joint motor fault grade protection: When the signal is lost or there is a risk of failure, the unloading / stop action is triggered within 10ms to prevent the robot from colliding with the surrounding environment or its own parts due to loss of control. The hardware damage rate caused by the fault is reduced from 30% to less than 5%.

[0019] c. Servo motor brake linkage: When the motor fails and the torque is zero, the brake lock is completed within 30ms, and the load drop distance is controlled within 1mm, achieving zero drop risk, which can meet the extremely high safety requirements of scenarios such as home and medical. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the interface connection of the embedded domain controller module of the present invention; Figure 2 This is a schematic diagram showing the connection method of the power management module; Figure 3 This is a schematic diagram of the soft-start control circuit of the present invention; Figure 4 This is a schematic diagram of the execution flow of the signal monitoring task task_los; Figure 5 This is a schematic diagram illustrating the layering of the task layer, driver layer, hardware layer, and mathematical function library of this invention.

[0021] Specific examples The present invention will be further described in detail below with reference to embodiments. These descriptions are for illustrative purposes only and are not intended to limit the scope of the invention.

[0022] This invention discloses a robot based on embedded domain control, which aims to solve the shortcomings of existing semi-humanoid robots in terms of hardware adaptability, software maintainability, operational safety and system coordination. It is achieved through hardware design, modular development and functional module collaborative control.

[0023] The hardware component serves as the physical foundation of the robot, providing the hardware carrier for power management, signal acquisition, and execution control, and providing interfaces and execution support for software and hardware collaboration. Modular development is based on a unified framework, which enables program portability and logical consistency, and carries the collaborative control logic of each functional module. Functional modules (power soft start, motor fault handling, brake linkage, signal monitoring, etc.) achieve safe startup, real-time protection and system monitoring of the robot through a collaborative mode of hardware execution and software tasks.

[0024] See Figure 1 A robot based on embedded domain control includes an embedded domain control module, a power supply, a power management module, and an actuator mounted on the robot's torso; the actuator includes a joint motor, a sensor, a servo motor, and a braking mechanism. The embedded domain controller module has a four-layer architecture of task layer, driver layer, hardware layer and mathematical function library, which realizes functional modularization based on task. The task layer is the top layer, which contains task files for deploying functional modules. A task file in the task layer contains the implementation logic or control program for a specified task based on the interface provided by the driver layer. The driver layer is an intermediate layer that encapsulates program packages that implement the various processes of the task module and provides a standardized function interface for calling according to task logic to the task layer or the same driver layer. The hardware layer is the bottom layer, which encapsulates the initialization and startup programs of peripherals with actuators, and provides standardized function interfaces for calling peripherals to the driver layer or task layer. The mathematical function library is a support layer that encapsulates the mathematical functions required to implement the specific functions in the functional modules and provides standardized function interfaces to the driver layer. When executing a task, the task layer calls the task module function interface of the driver layer and the peripheral function interface of the hardware layer according to the task logic, driving the corresponding peripheral device in the execution mechanism to execute the task.

[0025] The embedded domain controller module and functional modules are described in detail below.

[0026] (1) Embedded hardware design: Building the physical foundation for software and hardware collaboration The hardware component provides the underlying support for the robot's functionality. Its modular design accommodates multiple sensors and actuators, while also reserving software control interfaces, such as... Figure 1 As shown, it specifically includes: a. Embedded Domain Controller Module: An embedded domain controller module is used as the control module. This module is an MCU based on the ARM Cortex-M7 architecture; for example... Figure 1 As shown, the embedded domain control module is equipped with multi-channel GPIO interface, CAN bus interface, RS485 bus interface, USART communication interface, AD sampling interface, and PWM output interface, providing real-time data acquisition and command output channels for the software.

[0027] The embedded domain controller module also deploys a hardware-software co-operation program, which builds peripherals suitable for different hardware at the hardware layer, integrates co-operation control function interfaces at the driver layer, and deploys hardware-software co-operation control logic at the task layer.

[0028] b. Power management module: such as Figure 2 As shown, it includes a soft-start module connected to the power supply via an air switch and a DC contactor. The soft-start module receives a PWM signal sent by the embedded domain control module to adjust the starting current slope. The embedded domain control module controls the on / off of the total power supply to the upper body of the robot via the DC contactor. The power management module supports the control of the main power supply to the upper body of the robot via a DC contactor; it also supports the adjustment of the starting current slope via a PWM signal, providing an execution platform for software-based soft-start control.

[0029] The soft-start module includes a current control section and a power detection section; The current control section includes MOSFETs and PWM wave input circuitry; such as Figure 3 As shown, the MOSFET, as the main component for controlling the current, is connected in series to the negative terminal of the power supply. Its source is connected to the negative terminal of the power supply, and its drain is connected to the negative terminal of the robot load. An N-channel MOSFET is selected. The PWM wave input circuit converts the PWM wave signal output by the embedded domain control module (MCU) into a smooth DC signal by performing RC filtering. Then, the signal is amplified into a high-voltage, strong-drive signal by a transistor and input to the gate of the MOSFET. This controls the gate voltage to gradually turn on the MOSFET, thereby controlling the main circuit current to gradually increase.

[0030] The power detection section includes a sampling resistor connected in series to the negative terminal of the power supply's output circuit, and a voltage divider circuit connected in parallel with the sampling resistor; the ADC of the embedded domain control module measures the voltage of the voltage divider circuit to obtain the current value of the power supply circuit. Specifically, the power supply detection section is a current sampling circuit. A small-resistance, high-precision, high-power sampling resistor Rs is connected in series to the negative terminal of the power supply's output circuit. When the power supply output current I flows through the sampling resistor Rs, a small voltage difference Us is generated across the resistor. A resistor voltage divider circuit is designed to be connected in parallel with the sampling resistor Rs. The voltage across the voltage divider resistor is measured using the MCU's ADC. After parameter calculation and conversion, the current value of the power supply circuit can be obtained. For example, resistors R2 and R3 are connected in series and then in parallel with the sampling resistor Rs (R1). The voltage across the R2 voltage divider resistor is measured using the MCU's ADC, and the measurement result is U1. The current value of the power supply circuit can be calculated as I = (R1+R2+R3)·U1 / (R1·R2).

[0031] Both current control and circuit current sampling are handled by the MCU of the embedded domain control module. To ensure that the measurement error meets the control requirements, the signal input to the MCU is filtered and temperature drift compensated. In hardware, an RC circuit performs low-pass filtering on the signal, and a thermistor is used next to the sampling resistor to measure temperature changes. In software, the measurement results are processed using filtering algorithms, employing methods such as averaging multiple samples and moving average filtering to improve accuracy. Resistance values ​​at different temperatures are collected to create a temperature resistance calibration table, and the resistance value of the sampling resistor is corrected based on the measured temperature.

[0032] c. Motors and brakes: including articulated motors, servo motors, and braking mechanisms; Among them, the joint motor uses a collimated drive driver, which integrates the motor, reducer and driver into one, with a high degree of integration; while the servo motor integrates the motor and reducer into one unit, and uses a separate servo driver to control the servo motor. Configure a motor communication interface (hardware interface) for the joint motor and servo motor driver. This communication interface connects to the CAN bus or RS485 bus of the embedded control module. The embedded control module reads the motor's feedback information and status signals through the motor communication interface for real-time monitoring by the software. The braking mechanism includes an electromagnetic brake mounted on a servo driver and a brake relay connected to an embedded domain control module; the control terminal of the brake relay is connected to the output of an optocoupler isolation board, and the input of the optocoupler isolation board is connected to the GPIO interface of the embedded domain control module; the embedded domain control module controls the electromagnetic brake by switching the brake relay on and off; as... Figure 1 As shown, the brake relay is connected to the GPIO interface of the embedded pre-control module.

[0033] To prevent the load from falling when the servo motor has no output, an electromagnetic brake is used to restrain the servo motor output shaft. A brake control signal, i.e., a 24V high and low level control signal, is input through a brake relay to control the contact switch of the brake relay. When the relay is open, the power to the brake pads is cut off, and the servo motor output shaft brakes; otherwise, it does not brake.

[0034] d. By adopting a standardized interface and modular layout hardware design, the problems of chaotic hardware interfaces and poor interoperability in the current hardware are solved, enabling the embedded domain control module to control different hardware modules through unified instructions, thus laying a physical foundation for functional modularization and functional interoperability.

[0035] On the software side, sensors are divided into digital sensors and analog sensors. Digital sensors include photoelectric sensors, which detect the conduction signal of photoelectric pairs; analog sensors include force sensors, which detect the pressure signal at the end of the robot gripper. Digital and analog signals are acquired by configuring GPIO and ADC peripherals respectively. For different types of sensors, only the range and correspondence of the received analog signal values ​​need to be set in the software to call the same microcontroller pin to read the values ​​of different sensors.

[0036] For example, force sensors and temperature sensors return voltage ranges that are different. By setting the correspondence between voltage and force / temperature measurement force in the software, different hardware modules can be adapted using the same hardware pin.

[0037] (2) Functional modular development (software part): Building a highly portable collaborative control framework The software is designed based on a layered architecture and modular development, and is deployed in an embedded domain controller module to achieve program reusability and logical clarity. The embedded framework structure of this invention adopts a four-layer architecture of task layer, driver layer, hardware layer, and mathematical function library, where the task layer is the top layer, the driver layer is the middle layer, the hardware layer is the bottom layer, and the mathematical function library is a support layer, independent of other layers in the architecture.

[0038] a. The hardware layer implements the configuration of different peripherals, which mainly include CAN, SPI, USART, USB, timers, GPIO, etc. The hardware layer encapsulates the initialization and startup procedures for different peripheral functions, and provides standardized function interfaces to the driver layer or task layer, so that the upper layer does not need to pay attention to the details of the peripherals during use.

[0039] Taking CAN communication peripherals as an example, the task layer can call the peripheral initialization function to start or stop the CAN; the driver layer can call the CAN transmission function to send messages at the appropriate time.

[0040] b. The driver layer mainly contains programs that implement different task functions, including motor control, signal monitoring, inter-domain communication data processing, and USB communication data processing. The driver layer encapsulates the specific implementation programs for different tasks, providing standardized function interfaces to the task layer or driver layer. When the top-level task layer or the same-level driver layer implements a corresponding function, it only needs to call the function interface without needing to concern itself with the details of the function implementation.

[0041] Taking the motor drive task as an example, the drive layer of the motor drive encapsulates the processes of motor feedback data calculation, motor position control calculation, motor state update, and motor data transmission calculation. The task layer needs to call the corresponding functions according to the logic of the task to realize the motor drive task.

[0042] c. The task layer deploys control programs for specific functional modules, developed based on the interfaces provided by the driver layer. Each task file in the task layer contains the implementation logic for that task. To achieve real-time scheduling of each task, the software architecture uses the FreeRTOS operating system, based on which tasks and semaphores are created. FreeRTOS scheduling ensures that each task executes within a certain period, achieving real-time performance. Each task corresponds to a task file, and these tasks constitute the main body of the task layer.

[0043] d. The mathematical function library contains the mathematical functions (mathematical calculation programs) required to implement specific functionalities, including PID calculation, filtering functions, CRC check functions, ramp functions, etc. The mathematical function library encapsulates these specific functions and provides standardized function interfaces for the driver layer to call.

[0044] This software architecture isolates hardware differences, improving software portability by over 80%. Modular development ensures clear interactions between tasks, neat function encapsulation, and reasonable calls, greatly improving developer efficiency and shortening the development cycle of a single functional module to 1-2 weeks. Furthermore, the logic is clear and the software is highly readable.

[0045] In this software architecture, software and hardware co-operation programs can be deployed. Peripherals suitable for different hardware can be built at the hardware layer, co-operation control functions can be integrated at the driver layer, and software and hardware co-operation control logic can be deployed at the task layer, realizing multi-module collaboration throughout the process.

[0046] For example, in the hardware layer, the ADC, TIM, and GPIO peripherals in the embedded domain control module are configured, and function interfaces for peripheral startup and operation are reserved; in the driver layer, the task modules in the soft-start process are encapsulated, including calling ADC functions for current acquisition, data processing, outputting PWM waves to the current control circuit to control the current of the main circuit to increase slowly, and calling GPIO operation functions to realize the on / off switching of contactor contacts; in the task layer, the task module functions in the driver layer are called according to the logic of the soft-start task to finally realize the entire task.

[0047] (3) Power soft start control: a safe start mechanism based on hardware and software collaboration Typically, the upper body of a semi-humanoid robot can have up to 20 motors. When the power is turned on, there may be excessive current, which could damage the circuit board. To solve this problem, soft start can be achieved through real-time software monitoring and dynamic hardware adjustment.

[0048] The hardware foundation of this solution is as follows: The soft-start module in the power management module adjusts the current by controlling the conduction of the MOSFET, which is 0-100% and continuously adjustable. The current sampling resistor collects the loop current in real time and transmits the signal to the AD interface of the embedded domain controller.

[0049] The overall control program is deployed at the task layer, and the implementation of the solution is achieved through the following software control logic: a. Start-up phase: First, the DC contactor is closed by outputting a high level through GPIO; then, a PWM signal is output to the soft-start module, and the initial duty cycle is set; for example, the initial duty cycle is set to 10%, corresponding to 10% conduction.

[0050] b. Real-time adjustment: Read the current sampling value in real time (read every 10ms). If the current is less than 1.2 times the rated current, increase the PWM duty cycle at the set rate (5% / 10ms). If the current is greater than or equal to 1.2 times the rated value, pause the increase and maintain the current duty cycle until the current drops.

[0051] c. Startup complete: When the duty cycle reaches 100% and the current stabilizes for 300ms, the soft start ends and the program records the startup completion status.

[0052] Throughout the process, hardware execution is the foundation of soft start. The current control section and power detection section of the soft start module work simultaneously to perform the work of slowly increasing the current and sampling the current. Ultimately, the initial inrush current is controlled within 1.5 times the rated current to avoid overload damage to components and achieve the effect of hardware and software co-protection circuit from damage.

[0053] (4) Joint motor fault monitoring and protection: real-time response safety control mechanism To address the risk of signal loss or failure in the joint motor, safety control is achieved through embedded domain control for real-time monitoring and tiered protection measures. The hardware foundation of this solution is as follows: The joint motor controller communicates with the embedded domain controller module via a CAN bus to send status signals in real time, including the motor's position, speed, current, fault codes, etc.; the embedded domain controller hardware supports signal interrupt triggering.

[0054] The software monitoring and processing logic of this solution is as follows: a. Real-time monitoring: For fault monitoring in embedded systems, a dedicated task is set up for signal monitoring. This task is deployed at the task layer, named task_los (signal loss detection task), and a driver layer file driver_los is configured for this task.

[0055] The various signals input to the embedded domain controller are received at the hardware layer and processed at the task layer. The signal loss detection task counts each signal at the task layer, incrementing the counter by one every 50ms. At the signal receiver in the hardware layer, the counter for each signal is reset to zero. The signal must meet requirements such as a correct checksum and the normal motor status it represents. When the counter value exceeds a threshold, the signal is considered lost, thus achieving the purpose of signal monitoring. A flowchart of this task is shown below. Figure 4 As shown.

[0056] For motor signal monitoring, when task_los determines that a motor signal for a certain joint has been lost, the fault code in the last frame of the motor data packet is traced back to determine the abnormal state of the motor. If no fault code is found, the problem is a CAN bus signal loss. Different protection measures are taken for different motor abnormalities.

[0057] b. Graded processing: During normal operation, motors may encounter problems such as overheating, overload, driver chip failure, and bus signal loss. Among these, overheating is the most common. When a motor operates under high load, its internal temperature will continuously rise. When it exceeds a certain threshold, an overheating fault will be triggered. When an overheating fault occurs, a safety stop command is triggered, controlling the motor to enter a low-torque mode. Once the motor temperature returns to normal, the fault is cleared and the motor's torque output is restored.

[0058] Besides overheating, the most frequent motor fault is overload. To prevent overload, we first monitor the motor current. When the current approaches the threshold, we send a load reduction command to limit the motor output torque to less than or equal to the rated torque, and continue monitoring. When the current is less than the rated current, the motor returns to normal operation. Secondly, when an overload fault occurs, the motor immediately stops working. After the motor returns to normal, the fault is cleared and the motor resumes operation.

[0059] When a motor experiences an unrecoverable fault, such as a driver chip failure, a motor stop command is sent, and the motor status is recorded, awaiting reporting. If a CAN bus signal is lost, due to a communication timeout threshold, the motor will enter a disabled state if it does not receive a command within a certain period, preventing environmental damage due to loss of motor control. Simultaneously, the embedded system attempts to re-establish communication by restarting the communication and reports the situation to the user.

[0060] (5) Servo motor brake linkage control: a safety mechanism to prevent load drop. To address the risk of fall when the servo motor controlling the lifting mechanism has no output, protection is achieved through a combination of hardware and software mechanisms involving status monitoring and braking linkage.

[0061] The hardware foundation of this solution is as follows: the servo motor controller is connected to the embedded domain controller module via an RS485 bus, and the electromagnetic brake is controlled by the embedded domain controller module via a relay.

[0062] The software linkage logic of this solution is as follows: a. Status judgment: The task-level braking control task reads the status signal of the servo motor controller in real time (every 5ms). When the controller enters a disabled state due to a fault, the embedded domain control module controls the servo motor to stop torque output through the hardware layer.

[0063] b. Braking control: When the controller is detected to be in a disabled state and the motor output torque is less than the working torque, the high level is immediately output through the hardware layer relay drive to control the brake relay to engage, the electromagnetic brake is de-energized and locked, and the response delay is less than 30ms. When the controller is detected to have cleared the fault and entered the enabled state, and the motor output torque is the working torque, a low level is output first to release the brake, and the motor is allowed to move after a 50ms delay to avoid mechanical damage caused by rapid movement.

[0064] (6) Full signal monitoring and interaction with industrial control computer: system-level security monitoring mechanism By collaborating with embedded domain controllers and industrial control computers, the entire system can achieve signal monitoring and user interaction.

[0065] The hardware foundation of this solution is as follows: The embedded domain controller communicates with the industrial computer via a USB serial port to transmit signal status data, including the online status of the motor, the integrity of sensor data, and the operating status of each microcontroller in the domain controller.

[0066] The software linkage logic of this solution is as follows: Signal monitoring: The embedded domain controller's task_los function is configured with monitoring times ranging from 50 to 200 ms for different signals, including motor status, sensor data status, and communication status with other domain controllers. A signal health code is generated for each signal, with 0 representing normal and 1 representing abnormal.

[0067] Data Upload: Combine and package the health codes of all signals, and send them to the industrial control computer via USB serial port.

[0068] Industrial PC Response: After receiving abnormal information, the industrial PC will remind the user of the abnormal part through the human-machine interface, and at the same time send the action restriction command to the embedded domain controller to control the robot to enter a safe posture, such as retracting the arm or stopping movement, to avoid dangerous actions.

[0069] Specific implementation examples are given below.

[0070] Example 1 This example is for a wheeled humanoid robot, whose structure is as follows: the upper body is equipped with two seven-degree-of-freedom robotic arms and a two-degree-of-freedom head structure, the end of the robotic arms is equipped with a one-degree-of-freedom gripper, the torso has one translational degree of freedom, and the chassis is a three-omnidirectional wheel chassis. Its core functions are: the upper body can move flexibly to manipulate objects, the chassis can move in all directions, it supports VR remote operation, and the operator can see the field of view of the robot's head lens through VR glasses and control the robot through the handle.

[0071] Embedded domain controller module: It uses the STM32H723VGT6 chip with a maximum clock frequency of 550MHz and interacts with external devices through GPIO, CAN bus, RS485 bus, and USB-TypeC interface.

[0072] Power management module: includes DC contactor (24V coil), soft-start MOSFET (55V / 110A), and circuit breaker.

[0073] Motors and brakes: articulated motors, servo motor controllers, and brake relays (24V coils). The articulated motors and servo motor controllers communicate via CAN bus and RS485 bus, respectively.

[0074] Signal acquisition module: Includes an IMU module, which interacts with external devices via serial communication to provide data input for software decision-making.

[0075] The embedded domain controller module is deployed based on STM32CubeMX and CLion, employing a task-driver-hardware layer architecture. The hardware layer encapsulates peripheral initialization and startup programs, providing standardized interfaces. The driver layer implements the functions for different tasks, defining the specific steps involved. The task layer, based on FreeRTOS, creates each task, containing the logic for that task. The hierarchical architecture in this example is as follows: Figure 5 As shown.

[0076] For the power supply of the robot's upper body, a soft-start method is adopted. On the hardware side: the soft-start module in the power management module regulates the current by controlling the conduction of the MOSFET. The current sampling circuit collects the loop current in real time and transmits the signal to the AD interface of the embedded domain controller. On the software side, the overall control program is deployed in the task_motor layer. First, it executes the GPIO level output function to close the DC contactor, and then outputs a PWM signal to the soft-start module, with an initial duty cycle set to 10%. Through real-time adjustment, the conduction of the MOSFET is gradually increased to keep the total current stable below 1.5 times the rated current. When the conduction reaches 100%, the soft start ends.

[0077] To address the issue of load drop caused by potential servo motor failure, a hardware and software collaborative solution is adopted.

[0078] In terms of hardware: the servo motor controller is connected to the embedded domain controller via an RS485 bus, the braking mechanism is controlled by a relay (coil voltage 24V, contact capacity ≥5A), the relay control terminal is connected to the output of the optocoupler isolation board, and the input of the optocoupler isolation board is connected to the GPIO interface of the domain controller.

[0079] On the software side: The status signal of the servo motor controller is read every 5ms at the task layer. When the controller enters a disabled state due to a fault, a high level is immediately output through the hardware layer relay drive to control the brake relay to engage, the brake is de-energized and locked, and the response delay is less than 30ms. When it is detected that the controller has cleared the fault and entered the enabled state and the motor output torque is the working torque, a low level is output first to release the brake, and the motor is allowed to move after a 50ms delay to avoid mechanical damage caused by rapid movement.

[0080] To prevent and protect the robot from motor malfunctions, this solution is deployed in the task_los and reacts to different motor faults, providing protection. When a motor overheats, a safety stop command is triggered, controlling the motor to enter a low-torque mode. Once the motor temperature returns to normal, the fault is cleared and the motor's torque output is restored.

[0081] To prevent potential motor overload faults, the system first monitors the motor current to prevent overload. When the current approaches a threshold, a load reduction command is sent to limit the motor's output torque to less than or equal to the rated torque, and monitoring continues. When the current falls below the rated current, the motor resumes normal operation. Secondly, if an overload fault occurs, the motor immediately stops working. Once the motor returns to normal, the fault is cleared and the motor resumes operation. If an unrecoverable fault occurs, such as a driver chip failure or bus signal loss, a motor stop command is issued, and the motor status is recorded, awaiting reporting.

[0082] To provide timely and accurate feedback on system monitoring data to users, the robot's signal monitoring status will be displayed through the VR glasses interface, achieving comprehensive signal monitoring and feedback. The hardware configuration of this solution includes an STM32H7 connected to the industrial computer via a USB-Type-C interface at a baud rate of 12Mbps, and unique IDs assigned to each embedded module, motor, and sensor.

[0083] In the embedded domain controller, the `task_los` task is configured with different monitoring times ranging from 50 to 200 ms for different signals and generates signal health codes, where 0 represents normal and 1 represents abnormal. These signal health codes are packaged and sent to the industrial control computer via a USB serial port at a transmission frequency of 1 kHz. Upon receiving the abnormal information, the industrial control computer alerts the user to the location of the abnormality through a human-machine interface.

[0084] For example, when the robot's wrist joint stops working due to excessive load, a prompt box will appear on the VR glasses interface, and the robot can retract its arm to stop the robotic arm from working, preventing dangerous actions and verifying the effectiveness of monitoring system signals.

[0085] When replacing hardware, this invention only requires modifying the hardware layer driver code; at the same time, modular development allows individual functional modules to be debugged independently; operational safety is comprehensively enhanced, avoiding the risks of startup failure, motor runaway, and load drop, achieving zero drop risk, and meeting the needs of scenarios with extremely high safety requirements such as home and medical settings.

[0086] The embodiments given above are preferred examples for implementing the present invention, and the present invention is not limited to the above embodiments. Any non-essential additions or substitutions made by those skilled in the art based on the technical features of the present invention are within the protection scope of the present invention.

Claims

1. A robot based on embedded domain control, characterized in that, It includes an embedded domain control module, a power supply, a power management module, and an actuator mounted on the robot's torso; the actuator includes a joint motor, a sensor, a servo motor, and a braking mechanism. The embedded domain controller module has a four-layer architecture of task layer, driver layer, hardware layer and mathematical function library, which realizes functional modularization based on task. The task layer is the top layer, which contains task files for deploying functional modules. A task file in the task layer contains the implementation logic or control program for a specified task based on the interface provided by the driver layer. The driver layer is an intermediate layer that encapsulates program packages that implement the various processes of the task module and provides a standardized function interface for calling according to task logic to the task layer or the same driver layer. The hardware layer is the bottom layer, which encapsulates the initialization and startup programs of peripherals with actuators, and provides standardized function interfaces for calling peripherals to the driver layer or task layer. The mathematical function library is a support layer that encapsulates the mathematical functions required to implement the specific functions in the functional modules and provides standardized function interfaces to the driver layer. When executing a task, the task layer calls the task module function interface of the driver layer and the peripheral function interface of the hardware layer according to the task logic, driving the corresponding peripheral device in the execution mechanism to execute the task.

2. The robot based on embedded domain control as described in claim 1, characterized in that, The embedded domain controller module also deploys a software and hardware co-operation program, which builds peripherals suitable for different hardware at the hardware layer, integrates co-operation control function interfaces at the driver layer, and deploys software and hardware co-operation control logic at the task layer. The embedded domain control module integrates a multi-channel GPIO interface, a CAN bus interface, an RS485 bus interface, a USART communication interface, an AD sampling interface, and a PWM output interface, and provides real-time data acquisition and command output channels.

3. The robot based on embedded domain control as described in claim 1, characterized in that, The power management module includes a soft-start module connected to the power supply via an air switch and a DC contactor. The soft-start module receives a PWM signal from the embedded domain control module to adjust the starting current slope. The embedded domain control module controls the on / off of the total power supply to the upper body of the robot via the DC contactor. The soft-start module includes a current control section and a power detection section; The current control section includes a MOSFET and a PWM wave input circuit. The source of the MOSFET is connected to the negative terminal of the power supply, and the drain is connected to the negative terminal of the robot load. The PWM wave input circuit includes a filter that performs RC filtering on the PWM signal output by the embedded domain control module, which is then amplified and input to the gate of the MOSFET to achieve gradual turn-on of the MOSFET. The power detection section includes a sampling resistor connected in series to the negative terminal of the power supply's output circuit, and a voltage divider circuit connected in parallel with the sampling resistor; the ADC of the embedded domain control module measures the voltage of the voltage divider circuit to obtain the current value of the power supply circuit. Current control and power supply circuit current sampling are both handled by the embedded domain control module.

4. The robot based on embedded domain control as described in claim 3, characterized in that, The control program for adjusting the startup current slope of the soft-start module is deployed at the task layer, and its control logic is as follows: a. Startup phase: A high-level output is made through GPIO to close the DC contactor; then a PWM signal is output to the soft-start module and the initial duty cycle is set; b. Real-time adjustment: Read the current sampling value in real time. If the current is less than 1.2 times the rated current, increase the PWM duty cycle at the set rate. If the current is greater than or equal to 1.2 times the rated value, pause the increase and maintain the current duty cycle until the current drops; c. Startup complete: The soft start ends when the duty cycle reaches 100% and the current stabilizes.

5. The robot based on embedded domain control as described in claim 1, characterized in that, The articulated motor uses a collimated drive driver and communicates with the embedded domain control module via a CAN bus. The embedded domain control module monitors the articulated motor signals in real time, including the motor's position, speed, current, and fault codes. These signals are received at the hardware layer and the following monitoring is performed at the task layer: When the current value of the joint motor approaches the threshold, a load reduction command is sent to limit the output torque of the joint motor to less than or equal to the rated torque, and monitoring continues. When the current value of the joint motor is less than the rated current, it resumes normal operation; A communication timeout threshold is set for the joint motor. If the joint motor does not receive a command within a certain period of time, it enters a disabled state.

6. The robot based on embedded domain control as described in claim 1 or 5, characterized in that, The task layer also includes a signal loss detection task. This task counts each signal, incrementing the counter by one every cycle, and resetting the counter for that signal at the signal receiver in the hardware layer. When the counter value is greater than the threshold, the signal is considered to have been lost. When it is determined that a joint motor signal has been lost, the abnormal state of the joint motor is determined and classified by tracing back the fault code in the last frame of the motor data packet: If no fault code is found, the CAN bus signal is lost; the embedded domain controller module attempts to re-establish communication by restarting the communication and reports the situation. If the fault is determined to be an over-temperature fault, a safety stop command is triggered, and the joint motor is controlled to enter a low torque mode; once the motor temperature returns to the normal range, the fault is cleared and the torque output of the joint motor is restored; If the fault is determined to be an overload fault, the joint motor should be stopped immediately. Once the joint motor returns to normal, the fault should be cleared and the operation resumed. When an unremovable fault occurs in the joint motor, a joint motor stop command is sent, and the motor status is recorded.

7. The robot based on embedded domain control as described in claim 1, characterized in that, Each servo motor is equipped with an individual servo driver, which is connected to the embedded domain control module via a motor communication interface and an RS485 bus. The braking mechanism includes an electromagnetic brake mounted on a servo driver and a brake relay connected to an embedded domain control module. The brake relay control terminal is connected to the output of the optocoupler isolation board, and the input of the optocoupler isolation board is connected to the GPIO interface of the embedded domain control module; the embedded domain control module controls the electromagnetic brake by switching the brake relay on and off.

8. The robot based on embedded domain control as described in claim 7, characterized in that, The task layer includes a braking control task to perform servo motor braking linkage control to prevent the load from falling; its linkage control logic is as follows: a. Status judgment: The braking control task reads the status signal of the servo motor controller in real time. When the servo motor controller enters a disabled state due to a fault, the embedded domain control module controls the servo motor to stop torque output through the hardware layer. b. Braking control: When the servo motor controller is detected to be in a disabled state and the output torque of the servo motor is less than the working torque, a high level is immediately output through the hardware layer relay drive to control the brake relay to engage, and the electromagnetic brake is de-energized and locked. When the servo motor controller is detected to have cleared the fault and entered the enabled state, and the servo motor output torque is the working torque, the brake relay is released by outputting a low level through the hardware layer relay, and the servo motor is allowed to move after a certain delay.

9. The robot based on embedded domain control as described in claim 1, characterized in that, The task layer also includes a task_los task, which sets different monitoring times of 50~200ms for different signals, including monitoring of motor status, sensor data status, and domain control communication status; and generates a signal health code for each signal, where 0 represents normal and 1 represents abnormal. Data upload: Combine and package the health codes of all signals, and send them to the industrial control computer via USB serial port; Industrial PC Response: After receiving abnormal information in the health code signal, the industrial PC will remind the user of the abnormal part through the human-machine interface, and at the same time send a restriction action command to the embedded domain control module to control the robot to enter a safe posture.

10. The robot based on embedded domain control as described in claim 1, characterized in that, The sensors include digital sensors and analog sensors, each configured with GPIO and ADC peripherals to acquire digital and analog signals respectively. By setting the range and correspondence of the analog signal values ​​received in the embedded domain control module, the same microcontroller pin can be used to read the values ​​of different sensors.

Images